| Re: [AD] Color convertors |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Eric Botcazou wrote:
[snip]
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.
So if the color convertors support any widths, we can skip this intermedite
step?
This is because in BeOS you can switch the desktop color depth on the fly
while your program is running, and it must take care of the change (in our
case by changing the blitter function)
Under Windows too, but then Allegro crashes I think.
Can we catch this event? How hard would it be to switch the color convertor?
I understand there might be multi-threading issues, since the color
convertor might be running while the screen mode changes.
Can the color convertors run in a seperate (somehow syncronized) thread,
which can be terminated upon desktop resolution change?
Not very important IMHO (although we could catch the event and terminate the
program).
IMO changing desktop resolution should be supported in Allegro 4 without
crashing the Allegro program (or terminating it). It's part of a well
behaved windowed program. Besides, how many programs do you know that close
themselves when the destop rez changes?
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/