Re: [AD] Color convertors

["Angelo Mottola" <a.mottola@xxxxxxxxxx>]

>> I can't. The BeOS driver allows direct access to the VRAM in windowed
>> mode, by passing the application a serie of clipping rects that map to the
>> visible portions of the program window. You have to take care of updating
>> the window contents by writing directly to the vram only inside these
>> rects, that obviously can be of any size - including 1 pixel wide strips.
>
>Does the system continually pass clipping rectangles to the app or only when
>the window is being overlapped ?

The OS passes a new list of clipping rectangles every time a new one is 
needed, i.e. when the window is moved, or when another window overlaps with it 
changing its visible portions.

>The Win32 driver has got direct access to VRAM too so it must also take care
>not to draw onto other windows: when the window is in the foreground, the
>driver writes directly into VRAM (using only rectangles with 4-aligned
>width); when the window is being overlapped (hence will likely get paint
>requests), the driver switches into indirect mode where it first draws onto
>an intermediate bitmap (using again only rectangles with 4-aligned width)
>and then asks the system to clip and blit.

I see, but though not necessary, removing that 4-bytes alignment limit would 
be nice, don't you think? =)

>> This is because  in BeOS you can switch the desktop color depth on the fly
>
>Under Windows too, but then Allegro crashes I think.
>Not very important IMHO (although we could catch the event and terminate the
>program).

As already said, supporting desktop depth changes on the fly would be nice on 
every OS, not only BeOS. Terminating the program on the change doesn't look 
like an elegant solution anyways, so if it could be implemented in a more 
friendly way, it should be done IMO...

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com