Re: [AD] Color convertors

[Bob <ohannessian@xxxxxxxxxx>]

Eric Botcazou wrote:

> No, because the windowed driver knows that it is being overlapped but
> doesn't know which portion of the window is really hidden by another window.
> Windows (like X11) only sends 'paint' events ('expose' events for X11) to
> applications when a portion of the window that was previously hidden is
> visible again, not the opposite. So if the app updates a portion of the
> window that is under the overlapping window, the driver doesn't know that it
> must not draw onto the window. There is no other way than using the
> intermediate bitmap and asking the system to do the clipping.
> But there is virtually no performance loss when the window is in the
> foreground.

I see Windows was designed with the convenience of the programmers in mind :D



[snip]
> Not necessary, because we have already two threads: the main thread which
> draws onto the screen and performs the color conversion and the window event
> loop thread. When the latter catches the 'color depth switch' event, it
> could take the graphics mutex, which automatically halts every drawing
> operation for the other threads, instruct the windowed driver to change the
> color convertor and then release the mutex when it is done. However this is
> only a rough sketch and as always... the devil is in the details.


So the main thread will need to be suspended?


[snip]
> I would agree, but so far no user requested it (afaik) and this will require
> a major rewrite of the three windowed drivers (windowed, overlay and GDI).


Well, I think they would if they realised that you can't do what they may 
think you can do :)
Seriously though, if Allegro is to be used to make other things than games 
(and it is!), then it should play nice with the host OS.
It's not a priority though.


--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/