http://bugs.winehq.org/show_bug.cgi?id=421
--- Comment #109 from max@veneto.com 2009-01-30 10:22:25 --- (In reply to comment #108)
I took a look at the patch the other day. If I understand it correctly, when the DIB engine is enabled, doesn't it take over all DIB functions? Wouldn't a far better approach be to have the on/off switch, but also only replace the functions that are complete in the DIB engine? IIRC there is a list of function pointers stored in the DC, which are replaced by the DIB engine when it's enabled, is there a reason why these can't be switched on a one-by-one basis?
The matter is a bit more complicated. I've chosen Huw's approach (or Jesse's, they're quite similar) because this was the direction taken on latest intents. That doesn't mean that it's the better solution, but maybe that's the simpler solution to have dib engine introduced with no regressions and few changes on already stable GDI32 code.
The approach (as it is) uses 2 separate drivers, one for x11 and one for dib; each engine has its own set of function pointers AND its own physical device. All that means that you can't simply mix function of both drivers, because of different physical devices; it would be possible but the resulting code would be ugly, having to pass somehow the X11 physical device to the DIB one. Even more, the advantages would be minimal as using the X11 driver to support unimplemented DIB functions would mean to use all locking-conversion mechanism that is needed for the X11 driver, with its slow speed caveats.
A solution for the one-by-one replacement of X11 functions with dib ones would be to replace the function pointer table with a function-physdev pointer table, on which each function has its related physical device, but this one would slow somehow the createdc operation. Anyways, as we want the dib engine to be a complete replacement of the x11 one for dibs, that would be useful only during the development, so not a big advantage.
A "better" approach would have been (IMHO) to incorporate DIB engine in gdi32 code, but doing it now would require huge changes on gdi32 code with many possible regressions.
Ciao
Max