The DIB engine... does anyone know how to get it into Wine?
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. 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. 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? Any thoughts, I just want to spur some discussion on this because it seems that everyone that attempts a DIB engine hits a wall :) Luke.
i second the plea. Autocad is one of those applications that many windows users NEED to have working to even consider a change to linux, even at the enterprise level many would switch for it. the other day i had a friend in Naval Engineering ask me if it was possible to use Autocad in wine so he could use Linux, i had to sadly put his hopes down. 2009/4/28 Luke Benstead <kazade(a)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.
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.
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?
Any thoughts, I just want to spur some discussion on this because it seems that everyone that attempts a DIB engine hits a wall :)
Luke.
I think it's time that a definitive framework for it was agreed upon, because as people have said, this isn't the first time that someone has tried to implement the DIB engine. It's been on the todo list of improvements to Wine for as long as I can remember, but it seems as if every time someone tries to make good on that, that development gets so far but is then turned down on the grounds that the architecture isn't right. That's a lot of hours of wasted work. But then you'd expect that: it's a big project, and it's hampered by the fact that the current system has evolved to sort-of-work in a way that avoiding regressions is difficult if not impossible in the short term. It's logical that without some agreed upon roadmap, without some architectural pre-planning, any one person's attempt is going to come up short. -- Chris
2009/4/28 Chris Howe <mrmessiah(a)gmail.com>:
I think it's time that a definitive framework for it was agreed upon, because as people have said, this isn't the first time that someone has tried to implement the DIB engine. It's been on the todo list of improvements to Wine for as long as I can remember, but it seems as if every time someone tries to make good on that, that development gets so far but is then turned down on the grounds that the architecture isn't right. That's a lot of hours of wasted work.
But then you'd expect that: it's a big project, and it's hampered by the fact that the current system has evolved to sort-of-work in a way that avoiding regressions is difficult if not impossible in the short term. It's logical that without some agreed upon roadmap, without some architectural pre-planning, any one person's attempt is going to come up short.
-- Chris
Might I suggest that, as Huw, Jesse and Max have the most experience with what needs to be done, perhaps one or more of them could update this page: http://wiki.winehq.org/DIBEngine with what actually needs to change in GDI32 to allow for an incremental implementation of the DIB engine and also perhaps update the page with as much info about the current architecture, faults with the previous attempts etc. as possible. If there is more information out there about the problem, perhaps more people can contribute to coming up with a solution. Luke.
2009/4/28 Luke Benstead <kazade(a)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
Hi all, I was thinking just yesterday to a temporary solution that could, maybe, be useful without "disturbing" wine main workflow. My new approach has the structure of an "independent" driver which, even if it uses winex11 for DDB processing, is seen as a completely separated driver by gdi32. By its structure it's also quite independent of wine main tree, in sense that he needs just a very small patch of gdi32, and could be made also working without this patch. So, my proposal : the engine could be added to wine tree as a new, alternative driver. Then people could choose if use winex11 OR winedib. That temporary solution could stand up to the "right" approach to integrate the engine into gdi32 is found. Ciao Max
My personal final thoughts.... 1) It's obvious (but then, why we're repeating it forever ?) that final result is : DIB inside gdi32 and DDBs inside X11, with probably DIB cached to DDBs in x11 for performance reasons. 2) Assuming point 1, the *only* problem is to decide how get to it, so choose the best solution. 3) the "best" solution depends on zillions of personal factors. Here we say "you can't have full wine bottle and drunken bride". So, can we afford months of regression bugs ? Perfect, just start adding/replacing code to gdi32 AND winex11.drv and it's all ok. But then I guess I'll stay with wine-1.1.20 forever, resorting to wine-1.1.5 when I need something that mshtml regressions broke... We can't afford that ? so there's no other way than fork display driver and let people who needs it to test the new one up it becomes stable enough to replace the old one. I guess we could speak about it for years, but I really don't see another path that the 2 above. And, btw, I still don't know which would be the preferred one. The rest are simple implementation details. Max
2009/4/28 Massimo Del Fedele <max(a)veneto.com>:
My personal final thoughts....
1) It's obvious (but then, why we're repeating it forever ?) that final result is : DIB inside gdi32 and DDBs inside X11, with probably DIB cached to DDBs in x11 for performance reasons.
Agreed.
2) Assuming point 1, the *only* problem is to decide how get to it, so choose the best solution.
There are probably other problems/issues/considerations, but that is the big one.
3) the "best" solution depends on zillions of personal factors. Here we say "you can't have full wine bottle and drunken bride".
I would say that there are a lot of factors (forget the personal part).
So, can we afford months of regression bugs ? Perfect, just start adding/replacing code to gdi32 AND winex11.drv and it's all ok. But then I guess I'll stay with wine-1.1.20 forever, resorting to wine-1.1.5 when I need something that mshtml regressions broke...
The rationale behind small incremental changes is that it makes it easier to bisect. If there is one big bang patch, and there are a hundred regressions, it is harder to identify where they are. Also, smaller patches make it easier to review and to verify correct.
We can't afford that ? so there's no other way than fork display driver and let people who needs it to test the new one up it becomes stable enough to replace the old one.
I guess we could speak about it for years, but I really don't see another path that the 2 above. And, btw, I still don't know which would be the preferred one. The rest are simple implementation details.
The two things to get right are (1) the correct architecture and (2) an incremental migration strategy (i.e. a way to incrementally refactor the existing code to the new "DIB engine/support" code). Look at what is being done for the Direct3D 10 implementation, for example. Another benefit to the small incremental, always functional approach is that the code will be tested by everyone who uses Wine and not just people who are testing the side-line patches. The DIB engine is a huge undertaking. It is probably several years worth of effort to get right and requires a lot of knowledge to get right (both of Windows and Wine). - Reece
Reece Dunn ha scritto:
2009/4/28 Massimo Del Fedele <max(a)veneto.com>:
My personal final thoughts....
1) It's obvious (but then, why we're repeating it forever ?) that final result is : DIB inside gdi32 and DDBs inside X11, with probably DIB cached to DDBs in x11 for performance reasons.
Agreed.
2) Assuming point 1, the *only* problem is to decide how get to it, so choose the best solution.
There are probably other problems/issues/considerations, but that is the big one.
3) the "best" solution depends on zillions of personal factors. Here we say "you can't have full wine bottle and drunken bride".
I would say that there are a lot of factors (forget the personal part).
Personal part is always there, we're not machines :-)
So, can we afford months of regression bugs ? Perfect, just start adding/replacing code to gdi32 AND winex11.drv and it's all ok. But then I guess I'll stay with wine-1.1.20 forever, resorting to wine-1.1.5 when I need something that mshtml regressions broke...
The rationale behind small incremental changes is that it makes it easier to bisect. If there is one big bang patch, and there are a hundred regressions, it is harder to identify where they are. Also, smaller patches make it easier to review and to verify correct.
I agree, *when* it is possible. The question is..... it is ?
We can't afford that ? so there's no other way than fork display driver and let people who needs it to test the new one up it becomes stable enough to replace the old one.
I guess we could speak about it for years, but I really don't see another path that the 2 above. And, btw, I still don't know which would be the preferred one. The rest are simple implementation details.
The two things to get right are (1) the correct architecture and (2) an incremental migration strategy (i.e. a way to incrementally refactor the existing code to the new "DIB engine/support" code). Look at what is being done for the Direct3D 10 implementation, for example.
I'd agree with you, if I'd see a way to do it incrementally without forking driver and without breaking the whole. I didn't look at Direct3d 10, but I guess he don't affect zillions of apps, does it ? DX10 <--> Vista, and (AFAIK) most DX apps still use 9. Touching at gdi32 would break almost 100% of running apps if someting goes wrong.
Another benefit to the small incremental, always functional approach is that the code will be tested by everyone who uses Wine and not just people who are testing the side-line patches.
I'd agree again, *if* there is a way to do it incrementally. Sorry but I don't see any. You can't, for example, say "ok, let's fix line drawings routines, from now they'll be done from gdi32, and don't touch the rest, because of the way DIB are tied to X11 pixmaps. For line routines, for example, you must, *at once* : 1) patch the gdi32 part, to draw directly on dib 2) patch the x11 part to avoid current convert-modify-draw-convert stuff that is done now.... and *just* for line routines, if you don't want to touch at rest. 3) all above should be done for each DIB format, so you have to multiply the stuff by 8 4) probably check the polyline and other drawing stuffs that may use parts of line drawing. Don't forget rectangle filling, pattern drawing..... If you don't do 1+2+3+4 at once you'll have a regression. Even if you do you can, if something strange happens. Again, mshtml is a good example.... Nor can you take DIB away from X11 without patching the whole gdi32, or rewriting the whole X11 drv or both. There's no single routine in X11 that can be split/patched alone without affecting the whole, imho. Even just the "2 drivers approach" meant an handful of sparse hacks on many gdi32 routines.... and it was a "simple" approach.
The DIB engine is a huge undertaking. It is probably several years worth of effort to get right and requires a lot of knowledge to get right (both of Windows and Wine).
Here I don't agree. My engine is far from being perfect nor complete, and I'm surely not a gdi nor an x11 guru. Not even a programmer... My job is civil ingeneering. Nor I'm an extraterrestrial :-) But it works good enough for many apps. It's just a collection of well known snippets and algorithms and the result of some days of googling for documentation. I just made it to have AutoCAD usable and it does, speeding it up often 100:1. I think it would require a couple of months to complete with enough testers, an another month to optimize a bit. One year or something more of my spare time. Once completed, the stripping/modifying of DIB code in X11 would be quite straightforward. Then, and only then, the engine could be embedded in small patches inside inside gdi32.... just move the code from winedib.drv, routine by routine, making the winedib one just a forward call to the new X11 for the caching part. BTW, that's just my personal opinion, of course :-) Ciao Max
2009/4/29 Massimo Del Fedele <max(a)veneto.com>:
I didn't look at Direct3d 10, but I guess he don't affect zillions of apps, does it ? DX10 <--> Vista, and (AFAIK) most DX apps still use 9. D3D10 itself isn't used that much yet, most current D3D10 applications also have a D3D9 renderer. However, our d3d10 is based on wined3d, which is also used by ddraw, d3d8 and d3d9. So wined3d has to keep working while d3d10 is being implemented. I don't know enough about the internal x11drv and gdi32 architecture to judge if the scale is the same, but I suppose the concept is somewhat similar. I would of course expect Alexandre to be much more strict wrt. winex11.drv than wined3d since it's a much more critical component. I'd also expect reputation / experience with winex11.drv and gdi32 to be taken into account. I.e., trust, if you like.
Henri Verbeet ha scritto: I would of
course expect Alexandre to be much more strict wrt. winex11.drv than wined3d since it's a much more critical component.
of course :-) I'd also expect
reputation / experience with winex11.drv and gdi32 to be taken into account. I.e., trust, if you like.
I agree. That's why I've chosen the "new approach". As a new driver it can't break anything, so it could (but I guess it won't) be introduced as an "alternative" display driver in parallel to winex11. Ciao Max
On Wednesday 29 April 2009 1:58:53 am Massimo Del Fedele wrote:
That's why I've chosen the "new approach". As a new driver it can't break anything, so it could (but I guess it won't) be introduced as an "alternative" display driver in parallel to winex11.
A problem with it being a separate driver is that the other drivers need to know how to handle DIBs. If it's in a separate driver, I think that would break the encapsulation the drivers are supposed to have. Alexendre also doesn't like the idea of writing in "dead code" that's activated when finished. It makes regression testing a nightmare. My idea I've tossed around on IRC a couple times involves something like this: 1) Modify winex11.drv to handle DIBs using XImage, and not rely on Pixmap. Leave the pixmaps for DDBs. An XImage struct uses a vtable of sorts, so Wine can specify its own accessor functions, *and* provide the memory space the image is stored in (client-side). 2) Define a struct that replicates XImage, and put it in gdi32.dll. All display drivers would know of this struct, so winex11.drv can then use the new struct with very little change.. just change the XImage types where appropriate, and wrap the XImage around the DIB as needed (ie. so the new GDI32 type and the XImage work on the same image data). 3) Move left-over DIB processing from winex11.drv to gdi32.dll. The new XImage-like struct in GDI32 can then be modified as needed. That's a rather basic overview, of course.. but the people that've responded on IRC seem to think it's a good plan of attack.
It would be nice to see what Alexandre's opinion of the options discussed in this thread is, as he's ultimately the one who will decide.
From an observer's point of view, I'd say that moving the current DIB code out of wineX11 first before replacing it with Max's DIB code sounds like the cleanest idea, because then if any bugs are introduced it will be directly from the migration of the code, not the logic of the DIB stuff itself. But obviously, from reading the discussion, it's not as clean cut as just moving the code.
Luke.
On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead <kazade(a)gmail.com> wrote:
It would be nice to see what Alexandre's opinion of the options discussed in this thread is, as he's ultimately the one who will decide.
From an observer's point of view, I'd say that moving the current DIB code out of wineX11 first before replacing it with Max's DIB code sounds like the cleanest idea, because then if any bugs are introduced it will be directly from the migration of the code, not the logic of the DIB stuff itself. But obviously, from reading the discussion, it's not as clean cut as just moving the code.
Luke.
Yesterday there was a discussion on IRC about the DIB engine. To summarize it someone with a deep understanding of gdi32 should write the DIB engine and the only one right now who he think is capable of that is Huw. But he has no time to work on it right now (if there was funding for lets say half a year or so there might be time). Another solution might be (although I'm not sure if Huw is interested in that) is for him to mentor some people in working on the DIB engine. He would document how the DIB engine should be implemented and how it should interact with other parts of Wine. Roderick
2009/4/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>:
On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead <kazade(a)gmail.com> wrote:
It would be nice to see what Alexandre's opinion of the options discussed in this thread is, as he's ultimately the one who will decide. [Huw] would document how the DIB engine should be implemented and how it should interact with other parts of Wine.
Honestly, I think getting some agreed-upon documentation up would be the most helpful thing. -- Chris
2009/4/29 Chris Howe <mrmessiah(a)gmail.com>:
2009/4/29 Roderick Colenbrander <thunderbird2k(a)gmail.com>:
On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead <kazade(a)gmail.com> wrote:
It would be nice to see what Alexandre's opinion of the options discussed in this thread is, as he's ultimately the one who will decide. [Huw] would document how the DIB engine should be implemented and how it should interact with other parts of Wine.
Honestly, I think getting some agreed-upon documentation up would be the most helpful thing.
-- Chris
I agree. Luke.
On Wed, Apr 29, 2009 at 6:51 AM, Luke Benstead <kazade(a)gmail.com> wrote:
I agree.
Ditto. I made this point on IRC yesterday. No major project can move forward without a documented design and requirements. Unless these are forthcoming the DIB engine discussions are just going to keep amounting to noise with no signal. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
participants (9)
-
Chris Howe -
Chris Robinson -
Henri Verbeet -
Luke Benstead -
Massimo Del Fedele -
Reece Dunn -
Ricardo Filipe -
Roderick Colenbrander -
Steven Edwards