I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite.... also all bitmap's todo_wines, so expect some "false positive" signaled by tests.
Austin, could you please re-run it on your test machines ?
Ciao
Max
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele max@veneto.com wrote:
I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite.... also all bitmap's todo_wines, so expect some "false positive" signaled by tests.
Austin, could you please re-run it on your test machines ?
Sorry for the delay. New residence has crappy wireless internet, need to find a better solution.
Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
Yep, several todo's are passing now: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
Full report: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae... (The user32 failure can be ignored, I get that spuriously without DIB engine).
Austin English ha scritto:
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele max@veneto.com wrote:
I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite.... also all bitmap's todo_wines, so expect some "false positive" signaled by tests.
Austin, could you please re-run it on your test machines ?
Sorry for the delay. New residence has crappy wireless internet, need to find a better solution.
Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
Yep, I've seen it.... sorry, I checked out just the bitmap suite. It's trivial to fix, will do on next release
Yep, several todo's are passing now: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
too bad that the suite marks them as failures :-)
Full report: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae... (The user32 failure can be ignored, I get that spuriously without DIB engine).
Thank you for report. I still have to do a couple of optimizations, some font cleanups and then it'll be finished. I guess I'll setup a build machine for debian/ubuntu packages shortly.
Ciao
Max
2009/5/24 Massimo Del Fedele max@veneto.com:
Austin English ha scritto:
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele max@veneto.com wrote:
I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite.... also all bitmap's todo_wines, so expect some "false positive" signaled by tests.
Austin, could you please re-run it on your test machines ?
Sorry for the delay. New residence has crappy wireless internet, need to find a better solution.
Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010
http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
Yep, I've seen it.... sorry, I checked out just the bitmap suite. It's trivial to fix, will do on next release
Yep, several todo's are passing now:
http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
too bad that the suite marks them as failures :-)
Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed?
I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet?
On Sunday 24 May 2009 06:54:10 Ben Klein wrote:
Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed?
They are full tests, they're just marked as not passing in wine. Which they don't. At least not until wine has a DIB engine.
I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet?
It seems like Max and Alexandre agreed to disagree. I wouldn't hold my breath for this code to be merged to the main tree. Unfortunately, Max seems to like using Bugzilla to let people track his patches, instead of dumping them into some git tree, which would make keeping track of updates easier. His call of course.
Cheers, Kai
Kai Blin ha scritto:
On Sunday 24 May 2009 06:54:10 Ben Klein wrote:
Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed?
They are full tests, they're just marked as not passing in wine. Which they don't. At least not until wine has a DIB engine.
Most but not all of them. A few of them could be fixed anyways.
I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet?
It seems like Max and Alexandre agreed to disagree. I wouldn't hold my breath for this code to be merged to the main tree. Unfortunately, Max seems to like using Bugzilla to let people track his patches, instead of dumping them into some git tree, which would make keeping track of updates easier. His call of course.
The problem here is that I've got no time to maintain an updated git tree with my engine.... and I'm still fixing stuffs, so I prefere to manage my patchset directly in order to avoid a 1000+ patches on my tree. Dumping my patchset on a git tree wouldn't make its usage easier and would make me loose time and bandwidth to maintain it. People able to check out a git tree and build it are also able to apply the patchset to a clean one. It makes them spare time, too, as they don't have to maintain and build 2 different trees. With stacked git it's easy to add/remove the patchset. Anyways, if somebody wont take the (again, useless imho) job of maintain an updated tree with it, feel free to do it :-)
Ciao
Max
Ben Klein ha scritto:
2009/5/24 Massimo Del Fedele max@veneto.com:
Austin English ha scritto:
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele max@veneto.com wrote:
I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite.... also all bitmap's todo_wines, so expect some "false positive" signaled by tests.
Austin, could you please re-run it on your test machines ?
Sorry for the delay. New residence has crappy wireless internet, need to find a better solution.
Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010
http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
Yep, I've seen it.... sorry, I checked out just the bitmap suite. It's trivial to fix, will do on next release
Yep, several todo's are passing now:
http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae...
too bad that the suite marks them as failures :-)
Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed?
I guess not, wine is not passing them, and it won't pass most of them without a proper DIB engine. Some of them are independent of dib engine, indeed, and could be fixed anyways.
I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet?
Nope, and I think they will not be solved soon. Not by me, anyways. I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an "alternative experimental driver" in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever.
Ciao
Max
2009/5/24 Massimo Del Fedele max@veneto.com
I'm looking forward to this hitting upstream :) Have the architectural
issues been solved yet?
Nope, and I think they will not be solved soon. Not by me, anyways.
I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an "alternative experimental driver" in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever.
I assume all this took place on IRC because unless I missed it, Alexandre hasn't deigned to comment on here about what the right architectural solution would be.
Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches dissapear down a hole because they're "not right". Someone document what "would be right", or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions.
-- Chris
On Sun, May 24, 2009 at 12:04 PM, Chris Howe mrmessiah@gmail.com wrote:
2009/5/24 Massimo Del Fedele max@veneto.com
Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches dissapear down a hole because they're "not right". Someone document what "would be right", or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions.
Agreed. I would be willing to invest some time this summer in a DIB engine but it's impossible because of this. A wiki page describing the "right design" and what is needed in which component would be a great start. Maybe a goal for next WineConf?
I understand people are working on other important issues and that's much appreciated, but it's frustrating that so much valuable time has been spent on this (discussions and code) for years and see all attempts hit the same brick wall.
Jan de Mooij jandemooij@gmail.com writes:
On Sun, May 24, 2009 at 12:04 PM, Chris Howe mrmessiah@gmail.com wrote:
2009/5/24 Massimo Del Fedele max@veneto.com
Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches dissapear down a hole because they're "not right". Someone document what "would be right", or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions.
Agreed. I would be willing to invest some time this summer in a DIB engine but it's impossible because of this. A wiki page describing the "right design" and what is needed in which component would be a great start. Maybe a goal for next WineConf?
Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype, and then convince people (especially Huw and myself) that your design is good, that you know what you are doing, that you have anticipated the common objections and have good answers for them, that you are willing to make requested changes, that you have good test cases, etc. Showing that it more or less works on a couple of apps, or that it passes the (very few) existing gdi32 tests, is of course necessary, but by no means enough. If you want to tackle this, it will also help to have a good track record in getting simpler patches in first.
Once all of this is done and the proper design is in place in the tree, then there might be a number of fill-in-the-blanks tasks to implement the less common graphics calls that would probably be stubbed out in the first version. But we are nowhere near that point yet.
On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julliard@winehq.org wrote:
Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype,
Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet "anticipated common objections" etc.?
Zachary Goldberg zgold@bluesata.com writes:
On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julliard@winehq.org wrote:
Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype,
Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet "anticipated common objections" etc.?
Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far.
Alexandre Julliard ha scritto:
Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far.
Well, I still think that the "goodness" of a design is a matter of taste. My design is *a* design, started because of a personal need and evoluted by *my* personal taste, which was the only way I had without proper roadmap.
Btw, I thought to have explained enough the reasons of the choosen design, but I may be wrong.... so I'll put again here the pursued goals :
1) Something usable. That means something that don't work "just for a couple of apps" but that work in general at least as current driver do. This goal il about 90% to be reached, imho. It'll be 100% in a couple of monthes, if my job will let me enough spare time.
2) Something optional. There's no point, imo, to make a driver that breaks even just one app without the ability to fall back to original gdi32/winex11. Goal 100% reached.
3) Provide a working engine that allow in deep testing of speed difference. We know that *some* apps do benefit of it (again, autocad speed gain on TT fonts is something like 50x - 100x), but I've seen that recent thoughts were those of a limited speed gain.... Well, I think that many important apps could benefit of it. Goal 80% reached, as mixed blitting is something slower than original driver. No simple way to make it as fast without touching winex11.drv.
4) "prepare the road" to a definitive migration to what I think should be the "right final design", so DIBs handled by gdi32 double buffered by DDB inside winex11.drv; mixed blitting done inside winex11. I think that one would be the only viable way if we want blitting speed *and* DIB drawing speed. My driver is doing the needed separation of 2 processes. Once completed, moving them into gdi32/winex11.drv should be quite easy and could be done stepwise.
5) for fun. Ops, that one should be the n. 1 :-)
About point 4, which, I guess, is the most important for you, the next step would be to make a winex11-2.drv on which DIB processing would be stripped away, and with added DDB buffering of DIBs and mixed blit operations. That driver could be connected to (and tested with) winedib.drv, always as an option in registry/environment. Once ready and stable enough it should be made permanently enabled and remaining part of winedib.drv could be merged inside gdi32; that could also be made stepwise. Of course this design would mean some duplication of code in gdi32 and winex11.drv, at least if we don't want to change something in driver function tables.... which would be the best solution if it's not imposed by Microsoft behaviour (I didn't check that one, nor I think to do it for the moment). A simple GetLine() * PutLine() that do translation between 32 bit RGBA <--> DDB inside winex11.drv and callable by gdi32 would of course avoid all code duplication needed for mixed blitting, keeping needed speed. That addition would be trivial.
I think my design has some advantages and some disadvantages to other ones, but it's superior to the "double pointer approach" taken before, for reasons already explained. The main "disadvantage", maybe the only one, is to have for some time 2 different drivers in wine..... but OTOH it allows deep testing without breaking anything.
I hope I explained enough about it. Technical details are in (maybe too abundants...) code comments.
Ciao
Max
Massimo Del Fedele max@veneto.com writes:
About point 4, which, I guess, is the most important for you, the next step would be to make a winex11-2.drv on which DIB processing would be stripped away, and with added DDB buffering of DIBs and mixed blit operations. That driver could be connected to (and tested with) winedib.drv, always as an option in registry/environment. Once ready and stable enough it should be made permanently enabled and remaining part of winedib.drv could be merged inside gdi32; that could also be made stepwise. Of course this design would mean some duplication of code in gdi32 and winex11.drv, at least if we don't want to change something in driver function tables.... which would be the best solution if it's not imposed by Microsoft behaviour (I didn't check that one, nor I think to do it for the moment). A simple GetLine() * PutLine() that do translation between 32 bit RGBA <--> DDB inside winex11.drv and callable by gdi32 would of course avoid all code duplication needed for mixed blitting, keeping needed speed. That addition would be trivial.
I think my design has some advantages and some disadvantages to other ones, but it's superior to the "double pointer approach" taken before, for reasons already explained. The main "disadvantage", maybe the only one, is to have for some time 2 different drivers in wine..... but OTOH it allows deep testing without breaking anything.
One of the main problems I see is that your design is based on the premise that there's only one graphics driver, the X11 driver. That's clearly not the case, DIBs can be used with any driver (and with multiple drivers at the same time). This is also why you can't have the DIB driver decide on when to forward/not forward to the X11 driver, it should go in the other direction.
I'm also very skeptical about mirroring DIBs with a DDB. But even if you do this that should be a purely internal x11drv decision, the DIB engine shouldn't have any notion about this at all. This means you can't expose DIB->DDB conversion routines, DDBs are entirely up to the graphics driver.
Alexandre Julliard ha scritto:
Hi Alexandre,
One of the main problems I see is that your design is based on the premise that there's only one graphics driver, the X11 driver.
Well, I guess I expressed myself not completely corrected. My engine do load the winex11 exactly as gdi32 does. That means that in must not be winex11, it can be any driver that gdi32 would have loaded. The loading phase is like this :
GDI32 <-- load any driver and gets function pointers for DC and bitmap (ORIGINAL)
GDI32 <-- load winedib.drv <-- load any driver (etcetera) (MY WAY)
The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a "transient" phase, at the end all dib processing should go inside gdi32.
That's
clearly not the case, DIBs can be used with any driver (and with multiple drivers at the same time). This is also why you can't have the DIB driver decide on when to forward/not forward to the X11 driver, it should go in the other direction.
I'm also very skeptical about mirroring DIBs with a DDB.
Well, that was just a thought. I think that maintaining a mirrored DDB copy would slow down just a bit drawing operations but would speed up a lot blitting. But it's not a need.
But even if you
do this that should be a purely internal x11drv decision, the DIB engine shouldn't have any notion about this at all. This means you can't expose DIB->DDB conversion routines, DDBs are entirely up to the graphics driver.
I was meaning exposing a "stripped-extended" version of GetDIBits and SetDIBits, allowing partial image transfers. Again, that's not a need, it will just avoid code duplication in gdi32 and winex11. That would allow gdi32 to read and write portions of DDB with a call to winex11. Like it is now, you need knowledge of different DIB formats both in winex11 AND in gdi32; having this function would allow to move the "mixed blitting" stuffs almost completely inside gdi32. That's also just a suggestion. In my engine I have a bunch of PutLinexxx and GetLinexxx that do conversion from any format do 32 bit RGBA and vice versa; the functions I spoke about are just extensions of them for handling DDB conversion to/from 32 bit RGBA, and should reside, of course, in winex11.
I agree with you that the DDB caching of DIBs should be a winex11 stuff and totally transparent to gdi32.
Thanx for answers
Max
"Massimo Del Fedele" max@veneto.com wrote:
The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a "transient" phase, at the end all dib processing should go inside gdi32.
Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called "GDI font" (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new "font driver", so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing.
2009/5/27 Dmitry Timoshkov dmitry@codeweavers.com:
"Massimo Del Fedele" max@veneto.com wrote:
The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a "transient" phase, at the end all dib processing should go inside gdi32.
Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called "GDI font" (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new "font driver", so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing.
From what I gather, the desired architecture is to integrate DIB
engine into GDI32 wherever applicable (so the current DIB-related methods will be reimplemented with a possibly optional DIB engine). This also seems to be in keeping with Max's end-goal architecture - to integrate with GDI32.
A little while ago I was trying to run an app that uses Win16 DIB.DRV (I forget which app it was). My research indicated that although DIB.DRV was an actual driver (similar in architecture to Max's proposed DIB engine) in Win16 systems, in Windows 95 the functionality was rolled into GDI. For my app, this means that (in theory) exposing appropriate, existing DIB functions to my Win16 app in the form of a virtual DIB.DRV should work. For Max's engine, we're looking at diverging from Microsoft's modern architecture and switching back to something that was "good enough" 25 years ago.
We all know AJ wants things to be done "the right way" the first time. I agree with this policy, because it makes for more maintainable code, less duplication, etc. Wine's patch acceptance policy specifically prohibits "hack it until it works, then worry about it later" style programming, and the consensus of devs seems to be that adding a new DIB *driver* as an intermediary between GDI32 and hardware drivers is the wrong way to go about things.
Ben Klein ha scritto:
A little while ago I was trying to run an app that uses Win16 DIB.DRV (I forget which app it was). My research indicated that although DIB.DRV was an actual driver (similar in architecture to Max's proposed DIB engine) in Win16 systems, in Windows 95 the functionality was rolled into GDI. For my app, this means that (in theory) exposing appropriate, existing DIB functions to my Win16 app in the form of a virtual DIB.DRV should work. For Max's engine, we're looking at diverging from Microsoft's modern architecture and switching back to something that was "good enough" 25 years ago.
I begin thinking to not be clear enough in what I write...... 2 Last words:
1) Huw's starting engine *was* a driver's one, and many people told it was the right way. Worse, it forked driver from inside gdi32, which was awful to maintain.
2) My engine insertrs itself between gdi32 and the display driver; I begins to be tired repeating that it's a step through the final design on where DIB are handled fully inside gdi32. The step is, imho, necessary to split DIB handling from DDB without having to rewrite at once half of gdi32 + half of winex11.drv and maybe others. It is *not* the final step, now it wants to be. It's made so to prepare the switching in a painless way, *if* accepted. If not, just prepare to have the sampe problems we had with mshtml switching on each gecko change. In my case that broke a lot of stuffs.
We all know AJ wants things to be done "the right way" the first time. I agree with this policy, because it makes for more maintainable code, less duplication, etc.
again, I agree with that. Defining what is "the right way" is still a mysterious matter.
Wine's patch acceptance policy specifically
prohibits "hack it until it works,
which hack ????? then worry about it later" style
programming, and the consensus of devs seems to be that adding a new DIB *driver* as an intermediary between GDI32 and hardware drivers is the wrong way to go about things.
Strange enough, as the consensus on Huw's design was great, and it used a *real* external driver, and *not* an intermediate one as mine. But I start thinking that the requirements and consensus are very fluid and moving matters, lately.
Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point.
Last work about accepting or not hacks: I never proposed such patches. The most "hacky" stuff I sent (and was rejected, with a motivation that could be right) was the addition of page size handling inside wineps.drv. Motivation was that the printer driver shoul be rewritten for cups without lpr usage. I agree. But by now *is* using lpr and *is* lacking support for page size and other stuffs. So I asked myself : it's better to wait up we have the "complete right code", leaving the printer driver missing stuffs, or for the moment extend it while waiting for the right one ? I would have chosen the second solution, but as usual is a matter of taste.
Max
On Wed, May 27, 2009 at 2:11 AM, Massimo Del Fedele max@veneto.com wrote:
Strange enough, as the consensus on Huw's design was great, and it used a *real* external driver, and *not* an intermediate one as mine. But I start thinking that the requirements and consensus are very fluid and moving matters, lately.
Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point.
Not directed toward you, Massimo, but others:
Keep in mind, Massimo has sent patches dozens of times, along with explanations/critiques. Unless you have something *NEW* to add (check the archives), please refrain from commenting since in waste a lot of time.
Massimo Del Fedele wrote:
Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point.
Hi Max, would it be possible to craft a wikipage on Wine Wiki, that would encompass * official DIB implementation requirements * high level description of Huw's solution * description of Your solution incl. proposed integration plan
It would ease the orientation, prevent repeating the same stuff again and again and it could also serve as a solid base for further discussion about DIB integration requirements.
Regards Hark
On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy vit.hrachovy@sandbox.cz wrote:
Massimo Del Fedele wrote:
Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point.
Hi Max, would it be possible to craft a wikipage on Wine Wiki, that would encompass * official DIB implementation requirements * high level description of Huw's solution * description of Your solution incl. proposed integration plan
It would ease the orientation, prevent repeating the same stuff again and again and it could also serve as a solid base for further discussion about DIB integration requirements.
Regards Hark
I have asked Alexandre about it but it wasn't really an option. Even for Huw writing a full dib engine (if he resumed his current code) would take five months or so full time. Filling in the 'easy' bits (which Alexandre considers most of the things done so far) is not that much work (the easy bits are the software drawing functions).
Roderick
2009/5/27 Roderick Colenbrander thunderbird2k@gmail.com
On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy vit.hrachovy@sandbox.cz wrote:
would it be possible to craft a wikipage on Wine Wiki, that would
encompass
- official DIB implementation requirements
- high level description of Huw's solution
- description of Your solution incl. proposed integration plan
I have asked Alexandre about it but it wasn't really an option. Even for Huw writing a full dib engine (if he resumed his current code) would take five months or so full time. Filling in the 'easy' bits (which Alexandre considers most of the things done so far) is not that much work (the easy bits are the software drawing functions).
I'm not sure I understand this answer, as all but the first line doesn't seem to relate to the question. Are you saying that you have been told that making the documentation Vit described wasn't an option?
-- Chris
2009/5/27 Massimo Del Fedele max@veneto.com:
- Huw's starting engine *was* a driver's one, and many people told it was
the right way. Worse, it forked driver from inside gdi32, which was awful to maintain.
I can understand AJ preferring a fork of gdi32 to the intermediary driver given what he's said on this thread. He wants DIB to be integrated into gdi32 (which as I pointed out is also the way Windows does it). This is much easier to do if the DIB-enabled gdi32 can be used as a drop-in replacement for regular gdi32.
Of course, it also makes it more difficult to maintain, with any change in gdi32 needing to be mirrored in the forked DIB engine, but that's where git cherry-picking can come in handy :)
- My engine insertrs itself between gdi32 and the display driver; I begins
to be tired repeating that it's a step through the final design on where DIB are handled fully inside gdi32. The step is, imho, necessary to split DIB handling from DDB without having to rewrite at once half of gdi32 + half of winex11.drv and maybe others. It is *not* the final step, now it wants to be. It's made so to prepare the switching in a painless way, *if* accepted. If not, just prepare to have the sampe problems we had with mshtml switching on each gecko change. In my case that broke a lot of stuffs.
What I was trying to say with my post was not to rehash old ideas, but to say "here's where I feel you need to be going". AJ doesn't seem to like the intermediary driver which forwards non-DIB requests, so in order to get this into the upstream tree, what needs to be done is an integration with gdi32, as in replacing the DIB-related methods with the DIB-engine, instead of doing (what can be seen as a hack) redirection of selected methods.
I believe that if the majority of the intermediary design (with the intermediary driver) has been implemented and is working, it's time to start thinking of integrating it into gdi32 so that it is suitable for upstream inclusion.
HI Ben,
Ben Klein ha scritto:
Of course, it also makes it more difficult to maintain, with any change in gdi32 needing to be mirrored in the forked DIB engine, but that's where git cherry-picking can come in handy :)
Done for about 3 monthes, no more time for it :-)
What I was trying to say with my post was not to rehash old ideas, but to say "here's where I feel you need to be going". AJ doesn't seem to like the intermediary driver which forwards non-DIB requests, so in order to get this into the upstream tree, what needs to be done is an integration with gdi32, as in replacing the DIB-related methods with the DIB-engine, instead of doing (what can be seen as a hack) redirection of selected methods.
I believe that if the majority of the intermediary design (with the intermediary driver) has been implemented and is working, it's time to start thinking of integrating it into gdi32 so that it is suitable for upstream inclusion.
IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32.
Ciao
Max
On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele max@veneto.com wrote:
IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32.
It seems to me the best course is keep developing it outside of the tree until the remaining glitches are resolved and then try to resubmit it by moving in to gdi32. At least if Alexandre still wants to reject it due to remaining design issues, we have a good enough alternative.
Thanks
Hi Max,
From what I understand, the problem is not your design. I don't want
to put words in anyone's mouth, but to me it seems you and AJ agree on the final goal; Alexandre just doesn't want the "intermediary step" in the master tree (there could be many reasons for this). As you said, starting the move to gdi32 right now would be a huge waste of time (in maintenance and more), and prone to hell-knows how many regressions. You should get the DIB engine uploaded to its own repo or wine-hacks (http://repo.or.cz/w/wine/hacks.git). It's also been mentioned, but getting some documentation up and running on the wiki would be of great help. Maybe the authors of the previous DIB engine attempts could also give a shot at helping with that. People will also want (need) to know what they should test, how to test it, where to give feedback, what's still in the works, ...
You've done a great job so far, here's hoping it gets sorted :)
J
On Thu, May 28, 2009 at 10:46 PM, Steven Edwards winehacker@gmail.com wrote:
On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele max@veneto.com wrote:
IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32.
It seems to me the best course is keep developing it outside of the tree until the remaining glitches are resolved and then try to resubmit it by moving in to gdi32. At least if Alexandre still wants to reject it due to remaining design issues, we have a good enough alternative.
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
On Thu, May 28, 2009 at 6:58 PM, Jerome Leclanche adys.wh@gmail.com wrote:
Hi Max,
From what I understand, the problem is not your design. I don't want to put words in anyone's mouth, but to me it seems you and AJ agree on the final goal; Alexandre just doesn't want the "intermediary step" in the master tree (there could be many reasons for this). As you said, starting the move to gdi32 right now would be a huge waste of time (in maintenance and more), and prone to hell-knows how many regressions. You should get the DIB engine uploaded to its own repo or wine-hacks (http://repo.or.cz/w/wine/hacks.git). It's also been mentioned, but getting some documentation up and running on the wiki would be of great help. Maybe the authors of the previous DIB engine attempts could also give a shot at helping with that. People will also want (need) to know what they should test, how to test it, where to give feedback, what's still in the works, ...
You've done a great job so far, here's hoping it gets sorted :)
J
On Thu, May 28, 2009 at 10:46 PM, Steven Edwards winehacker@gmail.com wrote:
On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele max@veneto.com wrote:
IMHO, and really "in my opinion", loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32.
It seems to me the best course is keep developing it outside of the tree until the remaining glitches are resolved and then try to resubmit it by moving in to gdi32. At least if Alexandre still wants to reject it due to remaining design issues, we have a good enough alternative.
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
-- Jerome Leclanche
I completely agree with Jerome, and would like to add that tests of the DIB engine would probably be accepted into the tree. Since Max knows the finer notches of the DIB engine, taking the time to write some tests would seem to be a good idea - both to speed up the future migration and to make sure we're not missing any quirks. It may also help pinpoint certain bugs within the implementation.
Mike.
Dmitry Timoshkov ha scritto:
"Massimo Del Fedele" max@veneto.com wrote:
The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a "transient" phase, at the end all dib processing should go inside gdi32.
Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called "GDI font" (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new "font driver", so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing.
I begin to repeat stuffs too often lately. As I already wrote, *I know* and *I agree* that DIB should belong to GDI32. The proposed driver is a working step to that final goal. Point.
Max
On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard julliard@winehq.org wrote:
Zachary Goldberg zgold@bluesata.com writes:
On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julliard@winehq.org wrote:
Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype,
Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet "anticipated common objections" etc.?
Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far.
-- Alexandre Julliard julliard@winehq.org
Wouldn't a review of the proposed dib engine be useful? One that included concerns, things that needed to be changed etc? Everyone involved seems to be asking for leadership and guidance about how to proceed, wouldn't a thorough review of the proposed design give direction towards an "acceptable" design?
Chris
On Mon, May 25, 2009 at 9:32 PM, Chris Morgan chmorgan@gmail.com wrote:
On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard julliard@winehq.org wrote:
Zachary Goldberg zgold@bluesata.com writes:
On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julliard@winehq.org wrote:
Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype,
Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet "anticipated common objections" etc.?
Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far.
-- Alexandre Julliard julliard@winehq.org
Wouldn't a review of the proposed dib engine be useful? One that included concerns, things that needed to be changed etc? Everyone involved seems to be asking for leadership and guidance about how to proceed, wouldn't a thorough review of the proposed design give direction towards an "acceptable" design?
Chris
If it wasn't clear, I was suggesting that AJ and/or Huw would do this review since they have knowledge of the issue and an opinion of how it should be done :-)
Chris
Chris Morgan chmorgan@gmail.com writes:
Wouldn't a review of the proposed dib engine be useful? One that included concerns, things that needed to be changed etc? Everyone involved seems to be asking for leadership and guidance about how to proceed, wouldn't a thorough review of the proposed design give direction towards an "acceptable" design?
Of course, but a thorough review takes time, lots of time. If you want Huw or myself to invest that kind of time, you have to demonstrate that it's worth it. That was my point about first establishing a track record with simpler stuff.
The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff.
Alexandre Julliard ha scritto:
The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff.
Hi again :-)
Well, to be precise those were some patches rejected, one with some explanation and others not. Former was about adding page size support to wineps.drv. I haven't dropped it, but you told me that an almost complete rewrite of cups printers handling was foreseen and preferred, so I kept it on my tree. I have really not enough skills nor time to do such a complex job. My patch was just sending the missing page size string to lpr along as printer name, which is by now the only stuff sent. I can understand, of course, that going through lpr is not a very nice way. I'm using the patch for my daily job, it's not dropped.
Latters were one testcase (which was meant preparing some gdiplus patches....) which was rejected because "too long" and "with meaningless comments" and a couple of gdiplus functions that were missing (and are still missing) needed by autocad to run with builtin gdiplus, rejected because "contains errors" (possible, but which ?) and were "a pain to review" (hmmmm....). BTW, about comments, I'm sorry but my memory is not perfect and I tend to forget what I did and why after a couple of monthes, so the reason of maybe over-commenting all my code :-) I must say that the must difficult part of writing my engine was to try to figure out what gdi32/winex11 code does, and some comments more woul have been of great help !
Anyways, to finish, I'm coding for fun (ops, I guess I already said that) and I also have a job and a family that takes most of my time. If I don't see the possibility that my patches are accepted in a couple of tentatives, I tend to keep them on my "maybe useful stuffs" tree; otherwise if I see the possibility of having them published I can spend a bit more time on them. Of course a comment like "a pain to review" doesn't push me to work hard on it.....
Ciao
Max
Massimo Del Fedele wrote:
Alexandre Julliard ha scritto:
The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff.
Hi again :-)
Well, to be precise those were some patches rejected, one with some explanation and others not. Former was about adding page size support to wineps.drv. I haven't dropped it, but you told me that an almost complete rewrite of cups printers handling was foreseen and preferred, so I kept it on my tree. I have really not enough skills nor time to do such a complex job. My patch was just sending the missing page size string to lpr along as printer name, which is by now the only stuff sent. I can understand, of course, that going through lpr is not a very nice way. I'm using the patch for my daily job, it's not dropped.
Latters were one testcase (which was meant preparing some gdiplus patches....) which was rejected because "too long" and "with meaningless comments" and a couple of gdiplus functions that were missing (and are still missing) needed by autocad to run with builtin gdiplus, rejected because "contains errors" (possible, but which ?) and were "a pain to review" (hmmmm....). BTW, about comments, I'm sorry but my memory is not perfect and I tend to forget what I did and why after a couple of monthes, so the reason of maybe over-commenting all my code :-)
I tend to disagree with your self evaluation of 'too many'. There is NO such thing in coding. I've seen code with too little comments and then had to figure out what the heck the coder was trying to do inside the code. Of course, talking to the coder resulted in a "I know what I'm doing" conversation that resulted in no forward movement on a fixable problem that may have resulted in the company's demise.
I must say that the must difficult part of writing my engine was to try to figure out what gdi32/winex11 code does, and some comments more woul have been of great help !
This is very true. Code should at a minimum point out where the examples can be found. MSDN is very frustrating when it comes to how a piece of code is supposed to work.
What I see here is a lack of assistance from those who grade the code. This is what I consider unacceptable and has resulted in the stoppage of fixes being submitted by folks who 'code for food', that is they write code for a living. I evaluate and support programs for a living. Guess what? I don't recommend that folks use Wine on Macs for production level work. It just is not 'there'. Sadly, these same folks want to walk away from using Microsoft Software because, pardon the phrase, it just plain sucks. It is poorly written and full of bugs (and some of those bugs have been there for years.) I appreciate AJs efforts to keep the code base 'clean'. In the process, however, you have to tell folks what to do in order to keep the base clean. That is just plain being nice and is good ettiquitte. Otherwise, all you are doing is attempting to shoo away those who could really help move the project along and fix long standing problems. It does not take more time to state: Your code does not meet Wine standards because it has tabs in it", then to say "You can do better". Adding comments to what a certain chunk of code does is not expensive and it does make troubleshooting code much easier at a later time by a different person. One line comments are best.
So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival.
James McKenzie
On Wed, May 27, 2009 at 8:47 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival.
I'm not sure why it's a strange thing that the people that spend the most time with wine code have the most patches committed. To try and make an accusation that the project is restricted to paid peoples is both false and pointlessly inflammatory.
If there was a glut of manpower there'd be plenty of time to give full reviews of every patch. As it is everyone gives the time they can.
--John Klehm
2009/5/28 John Klehm xixsimplicityxix@gmail.com:
On Wed, May 27, 2009 at 8:47 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival.
I'm not sure why it's a strange thing that the people that spend the most time with wine code have the most patches committed. To try and make an accusation that the project is restricted to paid peoples is both false and pointlessly inflammatory.
If there was a glut of manpower there'd be plenty of time to give full reviews of every patch. As it is everyone gives the time they can.
It also depends where your experience lies. I am predominantly a UI developer, and having spent a long time writing UI code that is where I feel most comfortable working in. That does not mean that I know the behaviour of every Windows control inside and out, just that this is an area I feel capable of working on.
I am in awe of what the DirectX developers have done. I doubt I would be able to work in that area. Especially as I don't understand either DirectX or OpenGL. Same goes for the GDI/DIB engine code, the crypto code or a hundred other areas of the Windows API that Wine implements.
To work on an area of Wine, you need to have a deep understanding of how the Windows API works. For some areas (such as implementing the different Windows controls), you can do that purely through the Windows API. For other areas, you also need an understanding of how Linux/BSD/Mac/OpenSolaris/others implement that domain.
Wine has some very talented developers working on it. The problem comes when you have some functionality (like the DIB engine) that cuts across a large number of areas and requires a very deep understanding of both Windows and Linux/etc to grasp what needs to be done. And yes, that requires a lot of time and effort.
- Reece
On Monday 25 May 2009 15:03:17 Alexandre Julliard wrote:
Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design,
Does anyone have a mention about what a good design should be? My mention is that DIB driver should not exist at all. All DIB functions should be released inside GDI32 as some functions already released (such as CreateDIBSection, CreateBitmap etc.)
I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea.
Nope, and I think they will not be solved soon. Not by me, anyways. I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an "alternative experimental driver" in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever.
Ciao
Max
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea.
The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes....
Max
Massimo Del Fedele schrieb:
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea.
The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes....
Max
would you provide your builds for us?
André Hentschel ha scritto:
Massimo Del Fedele schrieb:
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea.
The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes....
Max
would you provide your builds for us?
Can do on next days. But I need some place on where to put the precompiled dlls... I guess nor bug421 page nor here are good places for it.
Ciao
Max
2009/5/25 Massimo Del Fedele max@veneto.com:
André Hentschel ha scritto:
I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea.
The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes....
To make this work and be as portable as possible, you'd need to produce pure win32 DLLs (not ELF/PE hybrid .dll.so files). You would then only need to distribute win32 and win64 variants, and not need to worry about all the different kernels/libc's Wine is capable of running on. :)
On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele max@veneto.com wrote:
André Hentschel ha scritto: No idea on what will happen with Mac or other unixes....
I am attempting a Mac build now. As with the rest of the discussion, It would be nice if we could produce a PE version using something like cygwin with X11 headers and the -mno-cygwin switch but I don't know if this would really work. If did then it should work on everything.
Thanks
Steven Edwards wrote:
On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele max@veneto.com wrote:
André Hentschel ha scritto: No idea on what will happen with Mac or other unixes....
I am attempting a Mac build now. As with the rest of the discussion, It would be nice if we could produce a PE version using something like cygwin with X11 headers and the -mno-cygwin switch but I don't know if this would really work. If did then it should work on everything.
Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX.
James McKenzie
On Sun, May 24, 2009 at 9:23 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX.
I think I am using the latest patch, its dibeng_max.zip thats got the 1-10 patches.
There are some major graphical glitches, though it could be related to me having Quartz Extreme and Quartz2d enabled on unsupported hardware. It does seem much faster though. Sorry I don't have time right now to do a complete report. I'll try to upload information to bugzilla in the morning after I make my environment a little more sane.
Thanks
Steven Edwards wrote:
On Sun, May 24, 2009 at 9:23 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX.
I think I am using the latest patch, its dibeng_max.zip thats got the 1-10 patches.
There are some major graphical glitches, though it could be related to me having Quartz Extreme and Quartz2d enabled on unsupported hardware. It does seem much faster though. Sorry I don't have time right now to do a complete report. I'll try to upload information to bugzilla in the morning after I make my environment a little more sane.
That's ugly. Did you attempt to type in something in the Document area?
I don't have the time tonight to attempt to build and run the DIB stuff to see what it does to the games and other programs that I work with.
Maybe, tomorrow afternoon after my bicycle ride.
James McKenzie
On Sun, May 24, 2009 at 10:19 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
That's ugly. Did you attempt to type in something in the Document area?
I've disabled all my Quartz hacks, the only thing sort of non-standard I have is my custom FreeType with patented engine enabled and support for SubPixel rendering turned on. Now that I think about it, that could be a problem. I'll try another round of testing with that disabled next.
Yes, it is MUCH faster rendering and scrolling and the like but there are minor glitches with the font placement in the document area. Notice how the word support and deployment overlap with the dib engine and how the lines alternate color? The speed difference for editing is like night and day. The header and footers for the document body containing images renders fine. Installers such as ie6setup and msxml3 embedded images don't render properly, I'll try to upload images for that as well in the morning. Bugzilla seems to be running quite slow so I can't upload the images there. Comparison screenshots for Word are here
http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_DibEng... http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_DibE...
Since this is not likely to get merged in anytime soon, lets move the rest of the OS X related discussions back to the bug when bugzilla decides to stop munching on the pesticide. I'll try to file more detailed reports as time permits.
Max this is wonderful progress, please keep up the good work!
Thanks
Steven Edwards ha scritto:
On Sun, May 24, 2009 at 10:19 PM, James McKenzie jjmckenzie51@earthlink.net wrote:
That's ugly. Did you attempt to type in something in the Document area?
I've disabled all my Quartz hacks, the only thing sort of non-standard I have is my custom FreeType with patented engine enabled and support for SubPixel rendering turned on. Now that I think about it, that could be a problem. I'll try another round of testing with that disabled next.
Yes, it is MUCH faster rendering and scrolling and the like but there are minor glitches with the font placement in the document area. Notice how the word support and deployment overlap with the dib engine and how the lines alternate color? The speed difference for editing is like night and day. The header and footers for the document body containing images renders fine. Installers such as ie6setup and msxml3 embedded images don't render properly, I'll try to upload images for that as well in the morning. Bugzilla seems to be running quite slow so I can't upload the images there. Comparison screenshots for Word are here
http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_DibEng... http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_DibE...
Since this is not likely to get merged in anytime soon, lets move the rest of the OS X related discussions back to the bug when bugzilla decides to stop munching on the pesticide. I'll try to file more detailed reports as time permits.
Max this is wonderful progress, please keep up the good work!
Thanks
He Steven,
Thank you for testing and for your words :-) The engine has still some known bugs (known by me :-) ) which are not spotter by wine testsuite, mostly related to coordinate spaces in xxxBlt functions. There is also a small stuff in AlphaBlend() with DDB as source, which is still not implemented, but should be trivial too. Another stuff that needs to be "fixed" is font handling; by now is not complete even if it's mostly functional: it does not kerning (you can see it easily on some apps, autocad too) and font sizes sometimes are wrong. All these stuffs should be trivial to fix, but I have really few time on these days, so it will take some time.
Ciao
Max
Massimo Del Fedele wrote:
The engine has still some known bugs (known by me :-) ) which are not spotter by wine testsuite, mostly related to coordinate spaces in xxxBlt functions.
Are they not spotted because the tests don't cover these? If so, would you be able/willing to add some tests to the test suite?
Paul Vriens wrote:
Massimo Del Fedele wrote:
The engine has still some known bugs (known by me :-) ) which are not spotter by wine testsuite, mostly related to coordinate spaces in xxxBlt functions.
Are they not spotted because the tests don't cover these? If so, would you be able/willing to add some tests to the test suite?
Paul:
Max knows about the problems and the tests. He just does not have the time right now to fix the problems and write the tests. He has hinted and asked others to help him. I have no knowledge of the DIB engine nor its processes, but I'd be willing to give it a go on the Mac, but I don't have any programs that appear to use the functions.
James McKenzie
-
Alexandre Julliard -
André Hentschel -
Austin English -
Ben Klein -
Chris Howe -
Chris Morgan -
Dmitry Timoshkov -
James McKenzie -
Jan de Mooij -
Jerome Leclanche -
John Klehm -
Kai Blin -
Massimo Del Fedele -
Mike Kaplinskiy -
Paul Vriens -
Reece Dunn -
Roderick Colenbrander -
Sergey Novosyolov -
Steven Edwards -
Vit Hrachovy -
Zachary Goldberg