Re: [PATCH] GSoC #09 Bitmap scaling

[Vesa Jääskeläinen]

Colin D Bennett wrote:
> On Mon, 13 Oct 2008 21:27:46 +0300
> Vesa Jääskeläinen <address@hidden> wrote:
>> Idea is that if bitmap is still locked you cannot optimize it or you
>> cannot lock it again. And if bitmap is optimized you cannot get
>> pointer to modify it. Eg. Function call returns memory pointer.
> 
> I thought perhaps the 'optimize' operation would simply return a _new_
> (and completely independent from that point forward) bitmap equivalent
> to the input bitmap but in the same format as the current video mode
> uses.

Problem with that is that it makes supporting code harder to use. With
only handful of supported formats it much easier to write support code
to modify bitmap. If you allow to use any format supported by video
subsystem it is nightmare to support them all.

So if we just support two formats. We only need to care about RGB and
RGBA formats, rather easy task. Can be modified by using simple loops or
indexing. When we know that there is no modifications to be done for
bitmap, we can just call optimize() and it will convert (edited) bitmap
to fast to blit format.

As we have same handle all the time for bitmap we can just continue to
use it as is. If we would make new instance of it, would either need to
delete previous one and replace its usage with new one. Of course use
case here affects.

> Are you thinking that it would be best to have the
> 'optimize'/'unoptimize' operations actually just modify the bitmap in
> place?  I guess this is nice from a memory conservation standpoint, but
> in some cases it wouldn't work well (i.e., 24-bit to 32-bit formats).

I do not think at this point how optimize() or unoptimize() will be
implemented. Just general idea. Whether it is in-place operation or
re-allocation for memory, is same to me. It just have to work :)

Thanks,
Vesa Jääskeläinen