HI Ben, Ben Klein ha scritto:
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 :)
Done for about 3 monthes, no more time for it :-)
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.
IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32. Ciao Max
