The DIB engine... does anyone know how to get it into Wine?

[Reece Dunn]

2009/4/28 Luke Benstead <kazade at gmail.com>:
> Hi all,
>
> I've been watching the DIB engine work that has been going on in bug
> 421. It looks like Max has made massive progress getting Autocad
> working by the sound of it, almost perfectly and also improvements in
> Starcraft have been reported. However, he accepts (and Alexandre has
> confirmed) that neither of the two approaches he has tried is the
> right one and he believes (as do others) that any correct approach
> requires massive changes to GDI32, which if I read it right, no one
> seems to know how to do incrementally.

So the first step is to get a solid design that has approval from
Alexandre. Max's work is great, but if it is not right architectually,
it is going to be further wasted effort.

What I would first ask is what architectural changes are needed in
gdi32? Get Alexandre's approval and input on this. If you don't know
what the restructured gdi32 will look like, how do you know how to
evolve it to that point.

There are refactoring techniques that allow you to gradually move
toward the new architecture, but if the end point (other than an
intangible idea of how this will work) is not known, the architecture
is likely to get worse.

IIRC, there are a few bug fixes and corrections in both Jesse's and
Huw's branches. It might be worth getting those in, as they should be
self-contained.

> Autocad is one of those apps, like Photoshop, which people need to be
> able to use and won't switch away from Windows without it. In fact,
> Autocad more so than Photoshop because there is no (almost) feature
> equivalent alternative available (like the GIMP for Photoshop). So
> it's frustrating to know that someone has it working, but vanilla Wine
> isn't going to see it working in the near future.

Sure. DIB engine support has been tried many times in many different ways.

> My question is this: does anyone know how to incrementally implement
> the necessary changes? Is it even possible? If it's not possible, is
> it work considering branching Wine to implement it correctly, for
> merging back into trunk at a later stage once it's been thoroughly
> tested? I'm wondering if Wine's development process just doesn't allow
> for a big change like this, and perhaps it's the development model
> that is the reason bug 421 is so long standing?

Sure, it is possible. However, trying to get in a set of patches that
(while they work, and improve performance) do not have the correct
architecture and have Alexandre's buy-in, they are going to collect
dust like all the other DIB engine attempts.

It should be possible to apply refactoring techniques, common sense
and patience to get Wine to the point where the DIB engine can be
supported cleanly.

> Any thoughts, I just want to spur some discussion on this because it
> seems that everyone that attempts a DIB engine hits a wall :)

1) Get the high-level design solidified and have Alexandre's approval.
2) Know what the scope of this is (e.g. is it going to support the
Eng* APIs? Or go through the GetDIBits APIs?).
3) How is it going to handle DIB and DDB differences?
4) Where is it going to interact with the X11 driver (and how much is
going to be offloaded to the DIB engine)?
5) Start small -- don't immediately expect to add the DIB engine
logic; evolve the gdi32 API to incrementally support the DIB engine
(e.g. build an interface that the DIB engine will hook into, but
implement it for the DDB/X11 code initially).
6) Expect this to take a *long* time and be a lot of hard work.
7) Consider improving the tests initially to cover DIB engine interactions.

- Reece