re: The DIB engine... does anyone know how to get it into Wine?
Max's work has been great in that a) he has found and fixed bugs that affect Autocad, and gotten those bugfixes into the trunk, and b) he is slowly working his way towards a DIB engine prototype that actually greatly improves speed on some important apps without hurting other apps. If I recall correctly, previous efforts stalled partly because they didn't actually provide a real speedup. So I'm really glad Max is doing what he's doing, even if it's not destined for the trunk, because he is nevertheless paving the way in some sense. - Dan
Hi, Massimo demonstrated the need for a DIB engine for Autocad but the way it is implemented is not fully correct. We already talked a bit about that on IRC. He is right that it should be implemented inside gdi32 and that it should be done in small steps (where possible). His idea is to add his 'DIB engine' and then fix the rest of the code and let everything converge in the end to the 'right' design. Part of the right design is that winex11.drv shouldn't work directly on DIBs anymore. Alexandre hasn't commented on the design except for saying that he didn't think that Massimo his current patches would converge to the 'right' design. Personally I think that the initial work for a DIB engine should focus on moving the DIB code away from winex11.drv. This is not a simple task and will likely require large patches. When all DIB code is abstracted away from winex11.drv adding a DIB engine will be a lot easier. Roderick
Keeping his patches up to date on bugzilla/wine-devel is also helpful for those testing. It may be a while before it can go it, but persistence pays off, and in the meantime, if those brave users willing to compile wine with a couple hacks can try it out and benefit, all the better. -- -Austin
Roderick Colenbrander ha scritto:
Hi,
Massimo demonstrated the need for a DIB engine for Autocad but the way it is implemented is not fully correct. We already talked a bit about that on IRC. He is right that it should be implemented inside gdi32 and that it should be done in small steps (where possible). His idea is to add his 'DIB engine' and then fix the rest of the code and let everything converge in the end to the 'right' design. Part of the right design is that winex11.drv shouldn't work directly on DIBs anymore.
Alexandre hasn't commented on the design except for saying that he didn't think that Massimo his current patches would converge to the 'right' design. Personally I think that the initial work for a DIB engine should focus on moving the DIB code away from winex11.drv. This is not a simple task and will likely require large patches. When all DIB code is abstracted away from winex11.drv adding a DIB engine will be a lot easier.
Roderick
Hi Roderick, The way I'm doing it is indeed seen by me as e temporary step for the migration and a way to "make things moving on" :-) Maybe I didn't spoke enough about the way I was planning when switched to the "new approach"... So I'll put it here. Maybe it can be useful for future plans. So : 1) Implement a "working" engine as an *alternative* driver; that's what my winedib.drv aims to be. It doesn't touch nor gdi32 (almost...) nor winex11; it's just a second choice driver with separed processing for DIBs. The fact that it uses winex11 is secondary and just an intermediate step. 2) when winedib.drv is working good enough, wanted to "detach" it from winex11.drv, so make another "driver" comprising DDB parts of wineX11 and all optimizations needed. I mean : DDB in the "other" winex11 driver, DIB in winedib BUT with a DIB copy in DDB format in the "other" winex11. That would optimize blitting on screen and from/to DDB/DIB. It would be a sort of double buffering of DIBs. 3) from steps 1/2, we resort with a winex11 driver without the DIB hassles AND all dib processing inside winedib. Last step would be to move the winedib code into gdi32 and replace the old winex11 with the new one. Steps 1-2 can be made without interfering with wine; step 3 would be made only when the engine is stable and tested enough to not cause regressions; it could also be made in small patches. Ciao Max
On Tue, Apr 28, 2009 at 8:13 AM, Massimo Del Fedele <max(a)veneto.com> wrote:
2) when winedib.drv is working good enough, wanted to "detach" it from winex11.drv, so make another "driver" comprising DDB parts of wineX11 and all optimizations needed.
This detaching thing is a little worrying. How will winex11 be called after detaching? Through winedib or gdi again? The first would not change functionality at all. The second is like the two driver method. It sounds like we ought to stick to the two separate drivers as a basis in development so we don't end up with something that can't be unglued easily.
On Tue, Apr 28, 2009 at 5:45 PM, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On Tue, Apr 28, 2009 at 8:13 AM, Massimo Del Fedele <max(a)veneto.com> wrote:
2) when winedib.drv is working good enough, wanted to "detach" it from winex11.drv, so make another "driver" comprising DDB parts of wineX11 and all optimizations needed.
This detaching thing is a little worrying. How will winex11 be called after detaching? Through winedib or gdi again? The first would not change functionality at all. The second is like the two driver method. It sounds like we ought to stick to the two separate drivers as a basis in development so we don't end up with something that can't be unglued easily.
We shouldn't introduce a temporary driver. I can't speak for Alexandre but I think he would prefer to let winex11.drv not directly touch DIBs and move it to gdi32 and I guess in a second step also move the conversion code over to gdi32 and work with some capability flags which the display driver uses to tell whether it can render at a certain depth or not. Depending on that gdi32 should execute the current conversion code. In a next step the DIB engine can be added. Roderick
Roderick Colenbrander ha scritto:
We shouldn't introduce a temporary driver.
Why ? I can't speak for Alexandre
but I think he would prefer to let winex11.drv not directly touch DIBs and move it to gdi32
Me too and I guess in a second step also move the
conversion code over to gdi32
agree too and work with some capability flags
which the display driver uses to tell whether it can render at a certain depth or not. Depending on that gdi32 should execute the current conversion code.
perfect In a next step the DIB engine can be added.
which next step ? then you'd already have the engine :-)
Roderick
Ciao Max
On Tue, Apr 28, 2009 at 7:48 PM, Massimo Del Fedele <max(a)veneto.com> wrote:
Roderick Colenbrander ha scritto:
We shouldn't introduce a temporary driver.
Why ?
I can't speak for Alexandre
but I think he would prefer to let winex11.drv not directly touch DIBs and move it to gdi32
Me too
and I guess in a second step also move the
conversion code over to gdi32
agree too
and work with some capability flags
which the display driver uses to tell whether it can render at a certain depth or not. Depending on that gdi32 should execute the current conversion code.
perfect
In a next step the DIB engine can be added.
which next step ? then you'd already have the engine :-)
No then you don't have the engine yet. In my proposal you would first make winex11.drv not depend on DIBs (the conversion code would still be in winex11.drv), then you move the conversion code over (you would still perform 8bit drawing using X by converting it to 24bit but this conversion would be done inside gdi32). In the third step you would add software based drawing functions, so the actual DIB engine. Roderick
Roderick Colenbrander ha scritto:
No then you don't have the engine yet. In my proposal you would first make winex11.drv not depend on DIBs (the conversion code would still be in winex11.drv),
uhmmm... and in the meanwhile where would be DIB processed ? then you move the conversion code over (you would
still perform 8bit drawing using X by converting it to 24bit but this conversion would be done inside gdi32).
That means taking a DIB, converting to a pixmap, send through x11, draw it, get it back from x11 and reconvert from inside gdi ? I guess you're replicating the "bad" behaviour of x11 driver just moving it to gdi32 and adding even more overhead.... In the third step you would
add software based drawing functions, so the actual DIB engine.
Roderick
It wouldn't be simpler just start with DIB code, let X11 manage a pixmap copy of DIB, so replicating the drawings via software from inside gdi32 AND with X11 on the replicated copy inside it ? I guess that one should be the final result... Why all these intermediate steps which btw don't bring any advantage ? I still see the behaviour simpler : 1) Make DIB code draw to DIBS, forward to X11 the rest. From gdi32 or from winedib.drv it's just a matter of taste.... former would be definitive solution, latter would allow deep testing without breaking anything. To see the former way, just look at mshtml code and its associated regressions..... 2) fork winex11.drv, putting inside all non-drawing and DDB stuffs from old winex11 and add brand new DIB<->DDB cached pixmap handling 3) when 2 is ready, jsut replace old winex11 with new one; if you choose the first way on step 1 you're ready, if you've chosen the second way,migrate winedib.drv code into gdi32. No regressions, no hassles, progressive and clean. Max
On Tue, Apr 28, 2009 at 9:32 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
On Tue, Apr 28, 2009 at 5:45 PM, Jesse Allen <the3dfxdude(a)gmail.com> wrote:
On Tue, Apr 28, 2009 at 8:13 AM, Massimo Del Fedele <max(a)veneto.com> wrote:
2) when winedib.drv is working good enough, wanted to "detach" it from winex11.drv, so make another "driver" comprising DDB parts of wineX11 and all optimizations needed.
This detaching thing is a little worrying. How will winex11 be called after detaching? Through winedib or gdi again? The first would not change functionality at all. The second is like the two driver method. It sounds like we ought to stick to the two separate drivers as a basis in development so we don't end up with something that can't be unglued easily.
We shouldn't introduce a temporary driver. I can't speak for Alexandre but I think he would prefer to let winex11.drv not directly touch DIBs and move it to gdi32 and I guess in a second step also move the conversion code over to gdi32 and work with some capability flags which the display driver uses to tell whether it can render at a certain depth or not. Depending on that gdi32 should execute the current conversion code. In a next step the DIB engine can be added.
Roderick
The reason for the DIB driver approach, was a way to separate out the DIB processing from winex11 without making any changes to it at the current time. This would help prevent breaking anything when the change was introduced. When I did my project, it was the top idea, so I showed how this could work. Huw has done some work based on this idea as well, and Max utilized both to fix problems in AutoCAD. I'm not sure if the DIB driver is being considered much by Alexandre anymore, so I've been hesitant to push for merging the code. Max said there were problems with the two driver approach. Your idea of moving DIB processing out of winex11, and then creating a DIB engine is a good idea, and I have been thinking much the same the past few days. We should if the driver approach is dead. Jesse
Jesse Allen ha scritto:
On Tue, Apr 28, 2009 at 8:13 AM, Massimo Del Fedele <max(a)veneto.com> wrote:
2) when winedib.drv is working good enough, wanted to "detach" it from winex11.drv, so make another "driver" comprising DDB parts of wineX11 and all optimizations needed.
This detaching thing is a little worrying. How will winex11 be called after detaching? .....
It simply won't be called. The "replacement" winex11 would contain the needed driver functionality. It's exactly the same as separating DIB from DDB from inside wineX11, but without the regression problems. The 2 winex11 drivers could remain as a stable and a development alternative. Once the replacement one is ready and tested, it would replace the old one. It's almost the same that happens with wine1.0 and the devel branch 1.1, with the difference that the new driver could be operated as an alternative to old one from the same build. Through winedib or gdi again? The first would not
change functionality at all. The second is like the two driver method. It sounds like we ought to stick to the two separate drivers as a basis in development so we don't end up with something that can't be unglued easily.
Well, now it *is* glued. That's just one way to unglue it. Ciao Max
participants (5)
-
Austin English -
Dan Kegel -
Jesse Allen -
Massimo Del Fedele -
Roderick Colenbrander