2009/4/28 Luke Benstead kazade@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