DIB Engine : passing all tests

Ben Klein shacklein at gmail.com
Thu May 28 02:23:09 CDT 2009

2009/5/27 Massimo Del Fedele <max at veneto.com>:
> 1) Huw's starting engine *was* a driver's one, and many people told it was
> the right way. Worse, it forked driver from inside gdi32, which was awful
> to maintain.

I can understand AJ preferring a fork of gdi32 to the intermediary
driver given what he's said on this thread. He wants DIB to be
integrated into gdi32 (which as I pointed out is also the way Windows
does it). This is much easier to do if the DIB-enabled gdi32 can be
used as a drop-in replacement for regular gdi32.

Of course, it also makes it more difficult to maintain, with any
change in gdi32 needing to be mirrored in the forked DIB engine, but
that's where git cherry-picking can come in handy :)

> 2) My engine insertrs itself between gdi32 and the display driver; I begins
> to be tired repeating that it's a step through the final design on where
> DIB are handled fully inside gdi32. The step is, imho, necessary to split
> DIB handling from DDB without having to rewrite at once half of gdi32 + half
> of winex11.drv and maybe others.
> It is *not* the final step, now it wants to be. It's made so to prepare
> the switching in a painless way, *if* accepted.
> If not, just prepare to have the sampe problems we had with mshtml
> switching on each gecko change. In my case that broke a lot of stuffs.

What I was trying to say with my post was not to rehash old ideas, but
to say "here's where I feel you need to be going". AJ doesn't seem to
like the intermediary driver which forwards non-DIB requests, so in
order to get this into the upstream tree, what needs to be done is an
integration with gdi32, as in replacing the DIB-related methods with
the DIB-engine, instead of doing (what can be seen as a hack)
redirection of selected methods.

I believe that if the majority of the intermediary design (with the
intermediary driver) has been implemented and is working, it's time to
start thinking of integrating it into gdi32 so that it is suitable for
upstream inclusion.

More information about the wine-devel mailing list