[Bug 421] Implement a DIB engine

http://bugs.winehq.org/show_bug.cgi?id=421

--- Comment #109 from [e-mail]  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