Jesse Allen ha scritto:
What about other drivers? Is the DIB driver going to know how to handle the others then?
The engine act as a filter between gdi32 and the DISPLAY driver, other stuffs are untouched. The changes on gdi32 are just to "prefere" the loading of the engine instead of normal display driver, IF the engine is available and IF it's enabled in registry/environment. When loaded, the engine resumes normal display driver loading, as was done previously in gdi32. Identical stuff, defaulting to wineX11.drv if not changed by registry key. The engine then forwards to X11 (or any other display driver) all calls related to DDB, and process directly the DIBS. He don't need to now anything about which display driver is loaded or it's internals... it just makes call to him as gdi32 do. This approach has 2 big advantages : 1) you don't have to fiddle with bitmap and dc function pointers inside gdi32, which revealed itself a very complicated and error prone stuff. Now gdi32 is unchanged. 2) having DIB engine acting as a display driver, it can be extended step by step to handle DDB too, if whished. Or, it can be made to handle only DIBs which format differs from X11 display's one, which are the true speed problem.
Does it even make sense to keep the DIB engine a driver anymore?
The alternative is, as usual, to rewrite a big part of gdi32 and x11 driver, and this can't be done step by step. The fact that X11 keeps a DDB copy of DIB inside it makes it almost impossible.
Jesse
Ciao Max
