DIB Engine : passing all tests
Massimo Del Fedele
max at veneto.com
Thu May 28 13:20:07 CDT 2009
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.
More information about the wine-devel