2009/5/27 Dmitry Timoshkov dmitry@codeweavers.com:
"Massimo Del Fedele" max@veneto.com wrote:
The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a "transient" phase, at the end all dib processing should go inside gdi32.
Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called "GDI font" (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new "font driver", so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing.
From what I gather, the desired architecture is to integrate DIB
engine into GDI32 wherever applicable (so the current DIB-related methods will be reimplemented with a possibly optional DIB engine). This also seems to be in keeping with Max's end-goal architecture - to integrate with GDI32.
A little while ago I was trying to run an app that uses Win16 DIB.DRV (I forget which app it was). My research indicated that although DIB.DRV was an actual driver (similar in architecture to Max's proposed DIB engine) in Win16 systems, in Windows 95 the functionality was rolled into GDI. For my app, this means that (in theory) exposing appropriate, existing DIB functions to my Win16 app in the form of a virtual DIB.DRV should work. For Max's engine, we're looking at diverging from Microsoft's modern architecture and switching back to something that was "good enough" 25 years ago.
We all know AJ wants things to be done "the right way" the first time. I agree with this policy, because it makes for more maintainable code, less duplication, etc. Wine's patch acceptance policy specifically prohibits "hack it until it works, then worry about it later" style programming, and the consensus of devs seems to be that adding a new DIB *driver* as an intermediary between GDI32 and hardware drivers is the wrong way to go about things.