2009/5/27 Massimo Del Fedele max@veneto.com:
- 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 :)
- 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.