Colin D Bennett wrote: > On Mon, 13 Oct 2008 21:27:46 +0300 > Vesa Jääskeläinen <[EMAIL PROTECTED]> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
