grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] GSoC #09 Bitmap scaling


From: Vesa Jääskeläinen
Subject: Re: [PATCH] GSoC #09 Bitmap scaling
Date: Fri, 03 Oct 2008 23:16:51 +0300
User-agent: Thunderbird 2.0.0.17 (Windows/20080914)

Vesa Jääskeläinen wrote:
> Vesa Jääskeläinen wrote:
>> It is really necessary that all generic graphical menu code like bitmap
>> scaler works always. Not just for some optimized formats as otherwise it
>> would render graphical menu unusable in some cases. It can be not so
>> pretty on low end systems, but it should at least work. That is the
>> reason there is map/unmap functions in video api.
>>
>> So there has to be first generic implementation and then you can use
>> optimized one if there exist one.
> 
> Just thinking as this is operating in a bitmap, we could just make sure
> we use only couple of formats and let video driver dot the rest. That
> would simplify it a bit.

Hi,

Now that Colin is back in action I am reviving this thread :).

I have been thinking this a bit and I think best solution to bitmaps is
something like following.

Two types of bitmap: easily accessible and optimized bitmaps for hardware.

Easily accessible are meant to be modified by user and provides slow
blitting performance. Basically we should only support two formats.
RGB888 and ARGB8888 (order can be different). This way we can make easy
code to modify bitmaps.

When there is no need to modify bitmap anymore, one calls
grub_video_bitmap_optimize(bitmap, rendering_target) and then bitmap is
optimized to match reder_targets format.

there would be two new helpers that gives access to bitmap data.
grub_video_bitmap_lock() and to release it grub_video_bitmap_unlock().
Lock will fail if bitmap is optimized.

I am wondering should we have grub_video_bitmap_unoptimize() to map back
to editable mode. But that might be more pain and promote bad ways to do
conversion.

Now bitmap loaders would be modified to return data in easily accessible
format so bitmaps can be modified and so on.

Now to bitmap scaling. This can only be done for easily accessible
formats and could be something like this:

+grub_err_t
+grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst,
+                                 int dst_width, int dst_height,
+                                 struct grub_video_bitmap *src,
+                                 enum
+                                 grub_video_bitmap_scale_method
scale_method);

Now in example static bitmaps would be optimized right away in order to
make their blitting fast. I do not know if we need special handling for
transparent bitmaps. May need some experimenting.

Actual scalers would be hidden from API and can only be specified by
enum type.

It could be a good idea to implement all scalers in same file. Unless
there is some weird scaler that needs thousands of lines of code.

Any opinions?

Thanks,
Vesa Jääskeläinen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]