Re: Status of DIB engine ?
Il 24/12/2011 08:59, Alexandre Julliard ha scritto: Massimo Del Fedele writes: So, the question : have I understood right from changelogs and text is completed in DIB engine, so I can help to make it a bit faster, or it's still missing something so I should just wait ? Text is done. Most likely Autocad is using some other call that still goes through X11. You should be able to see this in debug traces. Hi Alexander, that's weird, because when I developed the former engine, I solved the slowness just when I introduced text output. Anyways, I'll try to look at logs if I can find the problem. Max
Re: Status of DIB engine ?
Massimo Del Fedele writes: > So, the question : have I understood right from changelogs and text is > completed > in DIB engine, so I can help to make it a bit faster, or it's still missing > something so I should just wait ? Text is done. Most likely Autocad is using some other call that still goes through X11. You should be able to see this in debug traces. -- Alexandre Julliard julli...@winehq.org
Status of DIB engine ?
As I've got no idea of the status of DIB engine, besides looking at changelogs, I'd like to know it... at least to see if there's some need of help. The stuff that interests me at most is, as usual, the display speed of autocad with embedded truetype fonts (aka bug 13801), which depends deeply on DIB engine. From what I see in changelogs, text output seems to be completed; well, the speed of autocad text rendering has risen a *small* bit, but it's still unusable, light years far away from speed of my old engine which I'm still using for my job. So, the question : have I understood right from changelogs and text is completed in DIB engine, so I can help to make it a bit faster, or it's still missing something so I should just wait ? Max
Congratulations! DIB engine 421
Hi, Amazing I'm a long time follower of the project and to see a DIB engine implemented is a huge milestone given all the trials and tribulations leading up to it. Honestly never thought it would happen everyone needs to give themselves a pat on the back today :-) Regards, Keith
Re: Statur of DIB Engine
Il 25/07/2011 10:20, Huw Davies ha scritto: On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote: Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better. This is a good summary of where we're at - nicely done Octavian. The next step is cross-device blitting, which is what Alexandre and I are working on at the moment. Huw. Indeed that one was the big problem of my engine, impossible to do efficently without support from underlying drivers (winex11). Is font support for DIBS foreseen in short time ? Max
Re: Statur of DIB Engine
On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote: > Disclaimer: these comments are based only on what I gather from > following commits and looking at the code, so can't guarantee it's > 100% accurate; Huw or Alexandre would know better. This is a good summary of where we're at - nicely done Octavian. The next step is cross-device blitting, which is what Alexandre and I are working on at the moment. Huw.
Re: Statur of DIB Engine
Il 24/07/2011 19:32, James McKenzie ha scritto: On 7/24/11 10:14 AM, Massimo Del Fedele wrote: Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Max: It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work. It would give you a good start if Huw decides that your code is better than his! James Hi James, I guess that would be almost impossible to rebase my code there... For the few I've seen, the approach taken by Huw is too different from mine to have both coexistent, and the infrastructure changes would make the porting quite complicated and, which is worse, too dependent on code base changes to be maintainable by me. The only stuff that could be done would be to submit patches to enhance current graphics primitives but I guess Huw has already something in mind, and I've got too few spare time :-) Again, for what (very few indeed) I've understood from patches titles, some low-level primitives were exported from winex11 - gdi32 drivers, a stuff that was told me "impossible" when I developed my engine and that will make easy to solve the biggest problem remaining on it, the mixed DIB-DDB conversions in an efficient way. So, I'll wait to see what happens to Huw engine. A pity because latest progress in wine solved many other problems unrelated to DIB. Autocad users can just hope that fonts primitives will be embedded soon :-) Ciao Max
Re: Statur of DIB Engine
On 7/24/11 10:14 AM, Massimo Del Fedele wrote: Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Max: It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work. It would give you a good start if Huw decides that your code is better than his! James
Re: Statur of DIB Engine
Yep, true Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now. Thank you for your answer waiting for better times, so :-) Max
Re: Statur of DIB Engine
On Sun, Jul 24, 2011 at 4:11 PM, Massimo Del Fedele wrote: > Having seen many patches related to DIB engine lately, I built latest > sources and tried it No speed enhancements on AutoCAD, my test app. > So, I wonder if the engine is already working, at least partially, or not. > If yes, there's some switch/environment variable to enable it ? Hello, Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better. Most of the work so far was at an architectural level -- creating the infrastructure to support the incremental development of the DIB engine (see dlls/gdi32/dibdrv/). The new DIB engine is enabled by default, and is activated automatically (pushed onto the driver stack) if you pass a DIB to SelectObject. If the DIB engine doesn't implement some functions, they are forwarded to the next driver on the stack. If some features are not supported (eg. specific pixel formats; pen, or brush styles), it again falls back to the next driver on the stack each time those features need to be used (eg. drawing a line when current pen is not supported). Current status is: - most pixel formats are supported, if not all (1bpp is a bit special and still has some issues though); - most pens are implemented (except geometric pens, or pens with width greater than 1); - brush support looks pretty much complete; - most graphics primitives are NOT implemented yet. In fact, the only primitives that are currently implemented are LineTo, Rectangle, PaintRgn, and PatBlt (see [1]), the minimum to test that pens and brushes are working properly; no blits; no polygons, nor other weird shapes; no font rendering; not even get/set pixel. That's probably why Autocad doesn't show any improvements yet. On the other hand, the tricky architectural bits are mostly done, so I'm guessing visible speed improvements are not too far off. Octavian [1] http://source.winehq.org/git/wine.git/blob/8c850a82d440786ca4f83e5e061d6b3d323f5161:/dlls/gdi32/dibdrv/dc.c#l434
Statur of DIB Engine
Having seen many patches related to DIB engine lately, I built latest sources and tried it No speed enhancements on AutoCAD, my test app. So, I wonder if the engine is already working, at least partially, or not. If yes, there's some switch/environment variable to enable it ? Sorry for asking here but, besides of git commits I've seen no explanation about what's happening. Also some users of my old engine, which are blocked to an old wine version (it is no more applicable to git tree since some time, because of recent changes) would like to know what's going on. Ciao Max
[Fwd: Re: DIB engine]
To the list as well. Original Message Subject:Re: DIB engine Date: Mon, 01 Jun 2009 19:09:15 -0700 From: James McKenzie To: Andrew Eikum References: <1243755935.4535.1.ca...@stephan-desktop> <4a22ad55.5020...@brightnightgames.com> <4a22d65a.3030...@brightnightgames.com> Andrew Eikum wrote: > Austin English wrote: >> On Sun, May 31, 2009 at 11:16 AM, Andrew >> wrote: >> >>> My name's Andrew Eikum, I'm an undergraduate Computer Science >>> student at the >>> University of Minnesota. I contacted a Wine dev a few weeks ago >>> asking for >>> a small project to use to get familiar with Wine. I was pointed >>> towards the >>> gdiplus section and told to begin stubbing out the missing >>> functions, to >>> facilitate debugging. After familiarizing myself with how Wine's >>> DLLs are >>> built, and with Git, I'm now making quick progress. I expect to have a >>> (huge) patchset ready in the next week or two with most of the gdiplus >>> functions stubbed. >>> >>> After that, I plan to begin work on implementing some of the >>> functions. My >>> degree's emphasis is computer graphics, so working on gdiplus will >>> give me a >>> chance to learn more about the field as well as apply what I already >>> know. >>> I'm looking forward to working with other Wine devs on gdiplus, and >>> other >>> parts of Wine in the future. >>> >> >> Welcome to Wine! >> >> Be sure when sending patches to break them into small sets, with one >> change per patch. It makes it much easier to review that way, and if >> your patch causes a regression, much easier to identify which part if >> it's in multiple patches. >> > Thanks for the welcome! > > I am definitely doing small commits and following the WineGit wiki > page. One concern I have is that the number of patches will probably > be over 50 or even 75 -- I'm not sure if it'd be better to submit them > all in one go as they're pretty much all alike (just stubbing), or > just do batches of 5-10 every couple days as I finish them (so it's > not a deluge of patches). Any suggestions? > > > I'll second what Austin said. Please send in like the following: [1/2] Test for some gdiplus Windows function with todo_wine wrapper that demonstrates default Windows function from a source other than reverse-engineering (this is an absolute no-no.) [2/2] Code that implements the default function along with code to remove todo_wine wrapper. This way if your second code breaks something, the test will be in place and the todo_wine wrapper will remain. James McKenzie
Re: DIB engine
On Sun, 2009-05-31 at 12:23 -0700, Dan Kegel wrote: > On Sun, May 31, 2009 at 12:45 AM, Stephan Rose wrote: > >> If you're looking for something better specified, try finishing off > >> gdiplus. > > ... I'll check into gdiplus missing bits sometime next week. :) > > > > My name's Andrew Eikum, I'm an undergraduate Computer > > Science student at the University of Minnesota. > > I contacted a Wine dev a few weeks ago asking for a small > > project to use to get familiar with Wine. I was pointed > > towards the gdiplus section and told to begin stubbing > > out the missing functions, to facilitate debugging. > > After familiarizing myself with how Wine's DLLs are built, > > and with Git, I'm now making quick progress. I expect to > > have a (huge) patchset ready in the next week or two with > > most of the gdiplus functions stubbed. > > Excellent! (And Stephan, there's more than enough work > to go around, don't worry that Andrew's going to do it all :-) Hahaha, not worried. Btw, I seem to have a handle on the stringformat alignment bug. By the looks of it I may have a patch for that sometime over the next couple days. Don't know if I will make it today as I have a roughly 5'6" brunette incentive to do something other than write code tonight. :) Stephan
Re: DIB engine
On Sun, May 31, 2009 at 12:45 AM, Stephan Rose wrote: >> If you're looking for something better specified, try finishing off >> gdiplus. > ... I'll check into gdiplus missing bits sometime next week. :) > > My name's Andrew Eikum, I'm an undergraduate Computer > Science student at the University of Minnesota. > I contacted a Wine dev a few weeks ago asking for a small > project to use to get familiar with Wine. I was pointed > towards the gdiplus section and told to begin stubbing > out the missing functions, to facilitate debugging. > After familiarizing myself with how Wine's DLLs are built, > and with Git, I'm now making quick progress. I expect to > have a (huge) patchset ready in the next week or two with > most of the gdiplus functions stubbed. Excellent! (And Stephan, there's more than enough work to go around, don't worry that Andrew's going to do it all :-) > After that, I plan to begin work on implementing some of > the functions. My degree's emphasis is computer graphics, > so working on gdiplus will give me a chance to learn more > about the field as well as apply what I already know. > I'm looking forward to working with other Wine devs on > gdiplus, and other parts of Wine in the future. That's great to hear. Looking forward to seeing your patches. BTW, don't forget to look at http://wiki.winehq.org/GdiPlus, which has a few notes that might be helpful. My archive of Lei's notes at http://kegel.com/wine/sweng/2008/project.html from last year might be useful, too - it was tailored for people new to wine who want to contribute to gdiplus. (Though its big list of bugs is mostly all fixed now, I think only four remain.) - Dan
Re: DIB engine
On Sun, May 31, 2009 at 2:11 PM, Andrew Eikum wrote: > I am definitely doing small commits and following the WineGit wiki page. > One concern I have is that the number of patches will probably be over 50 > or even 75 -- I'm not sure if it'd be better to submit them all in one go as > they're pretty much all alike (just stubbing), or just do batches of 5-10 > every couple days as I finish them (so it's not a deluge of patches). Any > suggestions? No need to wait, go ahead and submit a couple. Since you're new to wine, it may take a couple days for them to get committed. Once you've got your feet wet and a few patches submitted, go ahead and submit a few more (5-10) a day. Try to avoid flooding wine-patches. The patches don't depend on each other, and it's not a huge rush to get them all in. And no need to wait to stub everything before sending implementations. If you've got it ready, and it works (add testcases to verify), send it in. Don't sit on your good patches, share them with everyone else :-). -- -Austin
Re: DIB engine
Austin English wrote: On Sun, May 31, 2009 at 11:16 AM, Andrew wrote: My name's Andrew Eikum, I'm an undergraduate Computer Science student at the University of Minnesota. I contacted a Wine dev a few weeks ago asking for a small project to use to get familiar with Wine. I was pointed towards the gdiplus section and told to begin stubbing out the missing functions, to facilitate debugging. After familiarizing myself with how Wine's DLLs are built, and with Git, I'm now making quick progress. I expect to have a (huge) patchset ready in the next week or two with most of the gdiplus functions stubbed. After that, I plan to begin work on implementing some of the functions. My degree's emphasis is computer graphics, so working on gdiplus will give me a chance to learn more about the field as well as apply what I already know. I'm looking forward to working with other Wine devs on gdiplus, and other parts of Wine in the future. Welcome to Wine! Be sure when sending patches to break them into small sets, with one change per patch. It makes it much easier to review that way, and if your patch causes a regression, much easier to identify which part if it's in multiple patches. Thanks for the welcome! I am definitely doing small commits and following the WineGit wiki page. One concern I have is that the number of patches will probably be over 50 or even 75 -- I'm not sure if it'd be better to submit them all in one go as they're pretty much all alike (just stubbing), or just do batches of 5-10 every couple days as I finish them (so it's not a deluge of patches). Any suggestions?
Re: DIB engine
On Sun, May 31, 2009 at 11:16 AM, Andrew wrote: > My name's Andrew Eikum, I'm an undergraduate Computer Science student at the > University of Minnesota. I contacted a Wine dev a few weeks ago asking for > a small project to use to get familiar with Wine. I was pointed towards the > gdiplus section and told to begin stubbing out the missing functions, to > facilitate debugging. After familiarizing myself with how Wine's DLLs are > built, and with Git, I'm now making quick progress. I expect to have a > (huge) patchset ready in the next week or two with most of the gdiplus > functions stubbed. > > After that, I plan to begin work on implementing some of the functions. My > degree's emphasis is computer graphics, so working on gdiplus will give me a > chance to learn more about the field as well as apply what I already know. > I'm looking forward to working with other Wine devs on gdiplus, and other > parts of Wine in the future. Welcome to Wine! Be sure when sending patches to break them into small sets, with one change per patch. It makes it much easier to review that way, and if your patch causes a regression, much easier to identify which part if it's in multiple patches. -- -Austin
Re: DIB engine
Stephan Rose wrote: On Sat, 2009-05-30 at 14:14 -0700, Dan Kegel wrote: Stephan Rose wrote: My ears perked up when the two words DIB and spec were put together in the same sentence. One frustration I encountered when wanting to contribute to wine a little over two years ago was that nobody seemed to be able to say "Hey, this is what we are missing/need, here are the specs, go implement". ... So if anyone can drop a full spec into my lap which outlines everything I need to write and where (given I adhere to things as I should of course) I won't have any issues getting that accepted later on... I don't think such manna is likely to fall from heaven any time soon. If it was that easy to spec, we would have been done by now. If you're looking for something better specified, try finishing off gdiplus. That's a somewhat well defined graphics package, and Wine's implementation has a few missing bits yet, last I checked. Ok, then judging from the last few posts i'll leave DIB be for now seeing how there still seems to be some figuring out to do and I'll check into gdiplus missing bits sometime next week. :) Thanks, Stephan I suppose this is as good a time as any to introduce myself. My name's Andrew Eikum, I'm an undergraduate Computer Science student at the University of Minnesota. I contacted a Wine dev a few weeks ago asking for a small project to use to get familiar with Wine. I was pointed towards the gdiplus section and told to begin stubbing out the missing functions, to facilitate debugging. After familiarizing myself with how Wine's DLLs are built, and with Git, I'm now making quick progress. I expect to have a (huge) patchset ready in the next week or two with most of the gdiplus functions stubbed. After that, I plan to begin work on implementing some of the functions. My degree's emphasis is computer graphics, so working on gdiplus will give me a chance to learn more about the field as well as apply what I already know. I'm looking forward to working with other Wine devs on gdiplus, and other parts of Wine in the future.
re: DIB engine
On Sat, 2009-05-30 at 14:14 -0700, Dan Kegel wrote: > Stephan Rose wrote: > > My ears perked up when the two words DIB and spec were put > > together in the same sentence. One frustration I encountered > > when wanting to contribute to wine a little over two years ago > > was that nobody seemed to be able to say "Hey, this is what > > we are missing/need, here are the specs, go implement". > >... > > So if anyone can drop a full spec into my lap which outlines > > everything I need to write and where (given I adhere to things > > as I should of course) I won't have any issues getting that accepted later > > on... > > I don't think such manna is likely to fall from heaven any time soon. > If it was that easy to spec, we would have been done by now. > > If you're looking for something better specified, try finishing off > gdiplus. That's a somewhat well defined graphics package, > and Wine's implementation has a few missing bits yet, last > I checked. Ok, then judging from the last few posts i'll leave DIB be for now seeing how there still seems to be some figuring out to do and I'll check into gdiplus missing bits sometime next week. :) Thanks, Stephan
Re: DIB engine
2009/5/30 Dan Kegel : > If you're looking for something better specified, try finishing off > gdiplus. That's a somewhat well defined graphics package, > and Wine's implementation has a few missing bits yet, last > I checked. OH YES PLEASE. (lots of apps missing bits of this - check over bugzilla and everything in it that's been stubbed) - d.
re: DIB engine
Stephan Rose wrote: > My ears perked up when the two words DIB and spec were put > together in the same sentence. One frustration I encountered > when wanting to contribute to wine a little over two years ago > was that nobody seemed to be able to say "Hey, this is what > we are missing/need, here are the specs, go implement". >... > So if anyone can drop a full spec into my lap which outlines > everything I need to write and where (given I adhere to things > as I should of course) I won't have any issues getting that accepted later > on... I don't think such manna is likely to fall from heaven any time soon. If it was that easy to spec, we would have been done by now. If you're looking for something better specified, try finishing off gdiplus. That's a somewhat well defined graphics package, and Wine's implementation has a few missing bits yet, last I checked. - Dan
Re: DIB engine
Ben Klein ha scritto: You would be surprised at how much of Wine is NOT a hack internally. Wine doesn't do hacks, Well, well there are some, indeed. Of course, it's better not add new ones :-) hence AJ's reluctance to include the current DIB proposal in Wine (to make it "correct" later will require a lot of hacking, as Max has objected). Again, my engine isn't a hack. Nor you'll need hacks to embed it on gdi32. Even more, some parts will be simplified because of direct access to internal gdi32 structures, which can't be done (without hacks) in current implementation. The *only* semi-hack is the direct access of gdifont struct from inside winedib it could also be avoided, but with much useless code added. Useless because it will be so once embedded in gdi32. Do we even have an architectural document or guidelines to reference? This was also raised on the existing thread. No. This is a problem. The best we have so far is "DIB engine should be integrated into GDI32". This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source. You got exactly the point :-) To be precise, the effort isn't so huge, but summed with the effort of maintaining all in sync with current tree the global effort would be great (and dumb, imho). Welcome aboard! I suggest that if you'd like to help out with the DIB engine (with the goal of getting it included to Wine upstream source), that you take a look at the code on bugzilla page #421 and talk to Massimo about how you might adapt it for integration into GDI32. There's not too much to adapt moving the engine inside gdi32 is (IMHO) not complicated at all. More a writing effort than a coding one. But, *before*, I guess winex11.drv (and any possible driver that does DIBs internally) should be patched stripping DIB handling *and* adding some stuffs for mixed transfers. Again, not an huge work, for somebody that knows well drivers internals. It could also be done later, if wished... but logically that would be the first step. Ciao Max
Re: DIB engine
"Stephan Rose" wrote: So if anyone can drop a full spec into my lap which outlines everything I need to write and where (given I adhere to things as I should of course) I won't have any issues getting that accepted later on, I'd be more than willing to take on something like this. Anyone needing a full spec can start here: http://msdn.microsoft.com/en-us/library/dd183562(VS.85).aspx If that's not enough just do it the way most of us are doing it every day: 1. write a test case 2. make the test pass under Wine -- Dmitry.
Re: DIB engine
2009/5/30 chris ahrendt : > > Question on this debate: > > Has AJ documented anywhere what the architectural issues are so they can > be addressed? This did not need a new thread. You should have posted it on the existing one. > I have not seen this in the thread and was just wondering. > If we have them documented then its a relatively easy task to address > each of them. > Yes it may be a hack but you would be surprised at how much of Windows > is a hack internally. You would be surprised at how much of Wine is NOT a hack internally. Wine doesn't do hacks, hence AJ's reluctance to include the current DIB proposal in Wine (to make it "correct" later will require a lot of hacking, as Max has objected). > Do we even have an architectural document or guidelines to reference? This was also raised on the existing thread. No. This is a problem. The best we have so far is "DIB engine should be integrated into GDI32". This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source. This leads me to my second point. 2009/5/30Z Stephan Rose : > My ears perked up when the two words DIB and spec were put together in the > same sentence. One frustration I encountered when wanting to contribute to > wine a little over two years ago was that nobody seemed to be able to say > "Hey, this is what we are missing/need, here are the specs, go implement". > Essentially, that's how I work and how I work well. Trying to fix random bugs > in random applications in a codebase completely unfamiliar to me seemed to be > rather futile so at that point in time I abandoned those efforts and just > stuck to using wine. =P > > So that said, I've got a decent amount of experiences dealing with graphics, > including full 24/32-bit color on embedded devices. Considering the > environment, performance has always been a priority as well. Plus, I also > really like working with graphics related code. So from where I'm standing > right now, this seems to be right in my neighbourhood. > > So if anyone can drop a full spec into my lap which outlines everything I > need to write and where (given I adhere to things as I should of course) I > won't have any issues getting that accepted later on, I'd be more than > willing to take on something like this. Welcome aboard! I suggest that if you'd like to help out with the DIB engine (with the goal of getting it included to Wine upstream source), that you take a look at the code on bugzilla page #421 and talk to Massimo about how you might adapt it for integration into GDI32.
Re: DIB engine
On 05/29/2009 12:28 PM, James Mckenzie wrote: >> As was said in the other thread, just designing it alone would take a >> few months work. AJ is really busy with other things, and a few months >> work is both a lot of money and a lot of wasted productivity. No one >> is stepping up to sponsor the work, so it's a bit hard for him to take >> that on. >> > Who is asking AJ to do all of the work. Huw Davies and Max have worked out > what is needed to get this into Wine. All we need is guidance on what is > acceptable and how we should proceed. This seems to be a serious shortcoming > on AJs part. Without this, any further work would be futile and could end up > being very frustrating. I've seen this from Huw and it is starting to come > from Max. AJ needs to get some time together and write up what is and is not > acceptable as far as code style, fashion and what he expects out of the > development efforts for the DIB engine. Making a statement > after months of work is IHMO very unacceptable. > > Also, I don't see this as circular, but the 'snake' of getting AJ to accept > code into the codebase is. > > Very respectfully submitted, > > James McKenzie > > > > Agreed James, this is the exact point I am getting at I guess... what exactly is acceptable and what is not... It seems we have a working solution for DIB. I do not think that it would take that long for AJ to sit down and say here.. this is what I want or this is what is acceptable then its up to the development people to come back and say ok here is our solution and then rectify the delta's in between. If Huw and Max have a solution then what is the delta? Chris
Re: DIB engine
>>As was said in the other thread, just designing it alone would take a >>few months work. AJ is really busy with other things, and a few months >>work is both a lot of money and a lot of wasted productivity. No one >>is stepping up to sponsor the work, so it's a bit hard for him to take >>that on. > >Who is asking AJ to do all of the work. Huw Davies and Max have worked out >what is needed to get this into Wine. All we need is guidance on what is >acceptable and how we should proceed. This seems to be a serious shortcoming >on AJs part. Without this, any further work would be futile and could end up >being very frustrating. I've seen this from Huw and it is starting to come >from Max. AJ needs to get some time together and write up what is and is not >acceptable as far as code style, fashion and what he expects out of the >development efforts for the DIB engine. Making a statement >after months of work is IHMO very unacceptable. > >Also, I don't see this as circular, but the 'snake' of getting AJ to accept >code into the codebase is. This is where I figured I'd wake up and chime in a bit. None of you all know me I suppose but I've been primarily just listening in on this list for the better part of two years now. :) My ears perked up when the two words DIB and spec were put together in the same sentence. One frustration I encountered when wanting to contribute to wine a little over two years ago was that nobody seemed to be able to say "Hey, this is what we are missing/need, here are the specs, go implement". Essentially, that's how I work and how I work well. Trying to fix random bugs in random applications in a codebase completely unfamiliar to me seemed to be rather futile so at that point in time I abandoned those efforts and just stuck to using wine. =P So that said, I've got a decent amount of experiences dealing with graphics, including full 24/32-bit color on embedded devices. Considering the environment, performance has always been a priority as well. Plus, I also really like working with graphics related code. So from where I'm standing right now, this seems to be right in my neighbourhood. So if anyone can drop a full spec into my lap which outlines everything I need to write and where (given I adhere to things as I should of course) I won't have any issues getting that accepted later on, I'd be more than willing to take on something like this. Thanks, Stephan
Re: DIB engine
James Mckenzie ha scritto: Luke: Heh, I wonder if someone should approach Autodesk and say, "Give us sponsorship and we'll get Autocad running on Linux" they surely have deep pockets :) If Autodesk were interested in making AutoCad work with Linux, they would make a native version, not try to get it working with Wine. Sorry, but them's the facts. Well, not exactly, I'm afraid. M$ did all possible (and even all almost impossible) to prevent simple porting of windows apps to other OS. DotNet is a good example of useless stuff, directx is another example. IMHO any app written using one of both of them will need an huge effort to port and an even greater effort to maintain on both platforms. Writing Autocad using a portable toolkit isn't an option, as most windows users (I guess 90% of autocad users, even if wi'd have a native version...) *want* to have their app looking as a native one. The only feasible stuff they could do is an effort to build it with winelib. Or, of course, help wine to make Autocad working perfectly on it. But I guess for them it isn't worth the money. Max
Re: DIB engine
Luke: > >Heh, I wonder if someone should approach Autodesk and say, "Give us >sponsorship and we'll get Autocad running on Linux" they surely have >deep pockets :) > If Autodesk were interested in making AutoCad work with Linux, they would make a native version, not try to get it working with Wine. Sorry, but them's the facts. Now, if you were to speak up with your wallet and donate to the effort, that is a vastly different story. Sadly, we are on our own to get AutoCad fully working with Wine. I don't expect any assistance from AutoDesk nor any of the major Linux players. James McKenzie
Re: DIB engine
>As was said in the other thread, just designing it alone would take a >few months work. AJ is really busy with other things, and a few months >work is both a lot of money and a lot of wasted productivity. No one >is stepping up to sponsor the work, so it's a bit hard for him to take >that on. Who is asking AJ to do all of the work. Huw Davies and Max have worked out what is needed to get this into Wine. All we need is guidance on what is acceptable and how we should proceed. This seems to be a serious shortcoming on AJs part. Without this, any further work would be futile and could end up being very frustrating. I've seen this from Huw and it is starting to come from Max. AJ needs to get some time together and write up what is and is not acceptable as far as code style, fashion and what he expects out of the development efforts for the DIB engine. Making a statement after months of work is IHMO very unacceptable. Also, I don't see this as circular, but the 'snake' of getting AJ to accept code into the codebase is. Very respectfully submitted, James McKenzie
Re: DIB engine
2009/5/29 Austin English : > On Fri, May 29, 2009 at 10:50 AM, chris ahrendt wrote: >> Right Austin, >> I have... thats why I asked the question why not sit down and say >> here is what we want from the DIB engine here is the Spec do this .. >> I have seen the here is what I don't like. But nothing showing what >> exactly is needed. This would be the first step in resolving this >> circular argument / discussion which is what I am trying to >> facilitate =D. Until that is done all we can do is have this same >> circular argument / discussion =D > > As was said in the other thread, just designing it alone would take a > few months work. AJ is really busy with other things, and a few months > work is both a lot of money and a lot of wasted productivity. No one > is stepping up to sponsor the work, so it's a bit hard for him to take > that on. > > -- > -Austin > > > Heh, I wonder if someone should approach Autodesk and say, "Give us sponsorship and we'll get Autocad running on Linux" they surely have deep pockets :) Luke. P.S. Must learn to reply to all, sorry Austin
Re: DIB engine
On Fri, May 29, 2009 at 10:50 AM, chris ahrendt wrote: > Right Austin, > I have... thats why I asked the question why not sit down and say > here is what we want from the DIB engine here is the Spec do this .. > I have seen the here is what I don't like. But nothing showing what > exactly is needed. This would be the first step in resolving this > circular argument / discussion which is what I am trying to > facilitate =D. Until that is done all we can do is have this same > circular argument / discussion =D As was said in the other thread, just designing it alone would take a few months work. AJ is really busy with other things, and a few months work is both a lot of money and a lot of wasted productivity. No one is stepping up to sponsor the work, so it's a bit hard for him to take that on. -- -Austin
Re: DIB engine
On 05/29/2009 11:14 AM, Austin English wrote: > On Fri, May 29, 2009 at 10:10 AM, chris ahrendt wrote: > >> Question on this debate: >> >> Has AJ documented anywhere what the architectural issues are so they can >> be addressed? >> I have not seen this in the thread and was just wondering. >> If we have them documented then its a relatively easy task to address >> each of them. >> Yes it may be a hack but you would be surprised at how much of Windows >> is a hack internally. >> >> Do we even have an architectural document or guidelines to reference? >> > If you read the entire thread, you'll see that the DIB design is not a > puzzle that can be carved out and dropped in. The DIB engine must be > designed from scratch. Designing the DIB architecture is half of the > work itself, since that involves planning a lot of the code/testing, > etc. > > He pointed out a few things he didn't like about Massimo's design, but > not a full 'here's the spec, do this exactly'. > > For more details, read the full thread and past discussions. > > -- > -Austin > > > Right Austin, I have... thats why I asked the question why not sit down and say here is what we want from the DIB engine here is the Spec do this .. I have seen the here is what I don't like. But nothing showing what exactly is needed. This would be the first step in resolving this circular argument / discussion which is what I am trying to facilitate =D. Until that is done all we can do is have this same circular argument / discussion =D chris
Re: DIB engine
On Fri, May 29, 2009 at 10:10 AM, chris ahrendt wrote: > > Question on this debate: > > Has AJ documented anywhere what the architectural issues are so they can > be addressed? > I have not seen this in the thread and was just wondering. > If we have them documented then its a relatively easy task to address > each of them. > Yes it may be a hack but you would be surprised at how much of Windows > is a hack internally. > > Do we even have an architectural document or guidelines to reference? If you read the entire thread, you'll see that the DIB design is not a puzzle that can be carved out and dropped in. The DIB engine must be designed from scratch. Designing the DIB architecture is half of the work itself, since that involves planning a lot of the code/testing, etc. He pointed out a few things he didn't like about Massimo's design, but not a full 'here's the spec, do this exactly'. For more details, read the full thread and past discussions. -- -Austin
DIB engine
Question on this debate: Has AJ documented anywhere what the architectural issues are so they can be addressed? I have not seen this in the thread and was just wondering. If we have them documented then its a relatively easy task to address each of them. Yes it may be a hack but you would be surprised at how much of Windows is a hack internally. Do we even have an architectural document or guidelines to reference? Chris
Re: DIB Engine : passing all tests
On Thu, May 28, 2009 at 6:58 PM, Jerome Leclanche 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 wrote: >> On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele 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.
Re: DIB Engine : passing all tests
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 wrote: > On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele 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
Re: DIB Engine : passing all tests
On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele 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
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
2009/5/27 Massimo Del Fedele : > 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. 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 :) > 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. 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.
Re: DIB Engine : passing all tests
2009/5/28 John Klehm : > On Wed, May 27, 2009 at 8:47 PM, James McKenzie > 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
Re: DIB Engine : passing all tests
On Wed, May 27, 2009 at 8:47 PM, James McKenzie 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
Re: DIB Engine : passing all tests
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" (h). > 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
Re: DIB Engine : passing all tests
2009/5/27 Roderick Colenbrander > On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy > 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
Re: DIB Engine : passing all tests
On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy 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
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
On Wed, May 27, 2009 at 2:11 AM, Massimo Del Fedele 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. -- -Austin
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
Dmitry Timoshkov ha scritto: "Massimo Del Fedele" 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
Re: DIB Engine : passing all tests
2009/5/27 Dmitry Timoshkov : > "Massimo Del Fedele" 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.
Re: DIB Engine : passing all tests
"Massimo Del Fedele" 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. -- Dmitry.
Re: DIB Engine : passing all tests
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.)
Re: DIB Engine : passing all tests
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" (h). 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
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
Chris Morgan 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 julli...@winehq.org
Re: DIB Engine : passing all tests
Massimo Del Fedele 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 julli...@winehq.org
Re: DIB Engine : passing all tests
On Mon, May 25, 2009 at 9:32 PM, Chris Morgan wrote: > On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard > wrote: >> Zachary Goldberg writes: >> >>> On Mon, May 25, 2009 at 7:03 AM, 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, 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 >> julli...@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
Re: DIB Engine : passing all tests
On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard wrote: > Zachary Goldberg writes: > >> On Mon, May 25, 2009 at 7:03 AM, 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, 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 > julli...@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
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
Zachary Goldberg writes: > On Mon, May 25, 2009 at 7:03 AM, 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, 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 julli...@winehq.org
Re: DIB Engine : passing all tests
On Mon, May 25, 2009 at 7:03 AM, 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, 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.?
Re: DIB Engine : passing all tests
Jan de Mooij writes: > On Sun, May 24, 2009 at 12:04 PM, Chris Howe wrote: >> 2009/5/24 Massimo Del Fedele >> >> 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. -- Alexandre Julliard julli...@winehq.org
Re: DIB Engine : passing all tests
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? -- Cheers, Paul.
Re: DIB Engine : passing all tests
On Sun, May 24, 2009 at 12:04 PM, Chris Howe wrote: > 2009/5/24 Massimo Del Fedele > > 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.
Re: DIB Engine : passing all tests
Steven Edwards ha scritto: On Sun, May 24, 2009 at 10:19 PM, James McKenzie 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_DibEngine_OS_X.png http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_DibEngine_OS_X.png 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
Re: DIB Engine : passing all tests
On Sun, May 24, 2009 at 10:19 PM, James McKenzie 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_DibEngine_OS_X.png http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_DibEngine_OS_X.png 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 "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: DIB Engine : passing all tests
Steven Edwards wrote: > On Sun, May 24, 2009 at 9:23 PM, James McKenzie > 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
Re: DIB Engine : passing all tests
Steven Edwards wrote: > On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele 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
Re: DIB Engine : passing all tests
On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele 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 "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: DIB Engine : passing all tests
2009/5/25 Massimo Del Fedele : > 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. :)
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
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?
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
2009/5/24 Massimo Del Fedele > 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
Re: DIB Engine : passing all tests
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
Re: DIB Engine : passing all tests
Ben Klein ha scritto: 2009/5/24 Massimo Del Fedele : Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele 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-ub904-dib/gdi32:palette.html 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-ub904-dib/gdi32:bitmap.html 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
Re: DIB Engine : passing all tests
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 WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: DIB Engine : passing all tests
2009/5/24 Massimo Del Fedele : > Austin English ha scritto: >> >> On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele >> 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-ub904-dib/gdi32:palette.html >> > 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-ub904-dib/gdi32:bitmap.html >> > 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?
Re: DIB Engine : passing all tests
Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele 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-ub904-dib/gdi32:palette.html 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-ub904-dib/gdi32:bitmap.html too bad that the suite marks them as failures :-) Full report: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/report.html (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
Re: DIB Engine : passing all tests
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele 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-ub904-dib/gdi32:palette.html Yep, several todo's are passing now: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:bitmap.html Full report: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/report.html (The user32 failure can be ignored, I get that spuriously without DIB engine). -- -Austin
DIB Engine : passing all tests
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
Re: DIB Engine - Mostly fixed against test suite
Giuseppe Bilotta ha scritto: I've started testing your patches (btw, the 9th patch in your series is missing the 0009- prefix although the 'series' file claims it should have; ops that was the hurry. stgit don't put the prefix, I added it manually just for who don't want to use it also, it's a real pity that git am doesn't accept stgit patches 8-/ but anyway, that's off topic). well, never used git-am, but I feel quite comfortable with stgit... also because it make easy to correct or integrate a commit An application that you might want to test your DIB engine against is Opera. Although there IS an Opera for Linux, the 64-bit Flash plugin has some subtle network bugs, and there is no Shockwave plugin at all, so it is still necessary for me to use Opera for Windows under Wine in a few cases. that's interesting I'll do it in short :-) Opera is a good test for your DIB engine because (1) it has problems with the current GDI32 stuff (2) it crashes with your DIB engine ;-) uhm see later, I'm afraid you didn't use the last posted engine... There is currently a bug that makes the 'native' skin for Opera hard to use because many widgets fail to display properly (invisible or totally black: http://bugs.winehq.org/show_bug.cgi?id=18553 ). Also the rendering of some Flash stuff is considerably buggy. quite interesting and a good testfield. As I'm restructurating a bit the code to solve the last 2 non conformity on testsuite, I guess I'll check it shortly :-) I was hoping to test Opera with your DIB engine to see if it works, and I came across this crash as soon as I tried rendering a webpage: =>0 0x7ee242c0 _CheckNotSysLevel+0x40(lock=0x7eaf8780) [/sources/wine/dlls/kernel32/../../include/winternl.h:1976] in kernel32 (0x0032e820) 1 0x7eac7020 GDI_CheckNotLock+0x20() [/sources/wine/dlls/gdi32/gdiobj.c:743] in gdi32 (0x0032e830) 2 0x7ea9c7f9 CreateCompatibleDC+0x19(hdc=(nil)) [/sources/wine/dlls/gdi32/dc.c:749] in gdi32 (0x0032e870) 3 0x7e8c4b2c _DIBDRVBITMAP_InitFromHBITMAP+0x24c(bmp=0x32e9b4, hbmp=, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=, startscan=, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/winedib.drv/dib.c:385] in winedib (0x0032ea60) 5 0x7ea9ec54 SetDIBits+0xf4(hdc=0x6138, hbitmap=0x6148, startscan=0, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/gdi32/dib.c:361] in gdi32 (0x0032eaa0) 6 0x7eaa05a3 StretchDIBits+0x233(hdc=0x6124, xDst=0, yDst=0, widthDst=7, heightDst=7, xSrc=0, ySrc=0, widthSrc=7, heightSrc=7, bits=0x67f97100, info=, wUsage=0, dwRop=13369376) [/sources/wine/dlls/gdi32/dib.c:295] in gdi32 (0x0032eb20) 7 0x7eb5255b LoadImageW+0x88b(hinst=0x6783, name=0x67f637f0, type=0, desiredx=7, desiredy=7, loadflags=8193) [/sources/wine/dlls/user32/cursoricon.c:2471] in user32 (0x0032ec40) 8 0x67b60b57 in opera (+0x330b57) (0x0032ecc4) That's the problem I'm solving with restructuration. In short, using GetDIBits and SetDIBits with a DIB bitmap instead a DDB (as I believed was the only usage for it) I ran into problem of getting DIB color table. GetDIBColorTable() is useless because it needs the bimpap to be selected on a DC, which is the opposite requirement for Get/SetDIBits; I can't create a temporary DC from inside them because of the SysLevel error you ran into. I obviously can't also use GedDIBits to get the color table (!) So I removed for the moment DIB handling from both function, and I'm coding the true solution, which is somehow complicated but almost done. In short, if you're interested, the solution is to keep a linked list of HBITMAP <--> Physical bitmap for all DIBs, which allow accessing color table and other useful stuffs without resorting to GDI, which should be faster and less problem-prone. I'll post the code in few days. For then, I guess ALL non-conformities to test suite will be solved. Ciao Max
Re: DIB Engine - Mostly fixed against test suite
On Wednesday 20 May 2009 00:13, Massimo Del Fedele wrote: > Well, it seems that the engine fixes some unrelated bugs too :-) > Bugs 15146 and 10408, as reported by a tester. > > BTW In a couple of weeks all (few) remaining failing tests should be fixed. > Then I'll try to optimize somehow the mixed blitting, which is the only > stuff that remains slower than original. > > Then, last but not least, I guess I'll setup a machine for weekly packaging > for ubuntu many people are asking me for autocad usage. I've started testing your patches (btw, the 9th patch in your series is missing the 0009- prefix although the 'series' file claims it should have; also, it's a real pity that git am doesn't accept stgit patches 8-/ but anyway, that's off topic). An application that you might want to test your DIB engine against is Opera. Although there IS an Opera for Linux, the 64-bit Flash plugin has some subtle network bugs, and there is no Shockwave plugin at all, so it is still necessary for me to use Opera for Windows under Wine in a few cases. Opera is a good test for your DIB engine because (1) it has problems with the current GDI32 stuff (2) it crashes with your DIB engine ;-) There is currently a bug that makes the 'native' skin for Opera hard to use because many widgets fail to display properly (invisible or totally black: http://bugs.winehq.org/show_bug.cgi?id=18553 ). Also the rendering of some Flash stuff is considerably buggy. I was hoping to test Opera with your DIB engine to see if it works, and I came across this crash as soon as I tried rendering a webpage: =>0 0x7ee242c0 _CheckNotSysLevel+0x40(lock=0x7eaf8780) [/sources/wine/dlls/kernel32/../../include/winternl.h:1976] in kernel32 (0x0032e820) 1 0x7eac7020 GDI_CheckNotLock+0x20() [/sources/wine/dlls/gdi32/gdiobj.c:743] in gdi32 (0x0032e830) 2 0x7ea9c7f9 CreateCompatibleDC+0x19(hdc=(nil)) [/sources/wine/dlls/gdi32/dc.c:749] in gdi32 (0x0032e870) 3 0x7e8c4b2c _DIBDRVBITMAP_InitFromHBITMAP+0x24c(bmp=0x32e9b4, hbmp=, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=, startscan=, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/winedib.drv/dib.c:385] in winedib (0x0032ea60) 5 0x7ea9ec54 SetDIBits+0xf4(hdc=0x6138, hbitmap=0x6148, startscan=0, lines=7, bits=0x67f97100, info=0x180528, coloruse=0) [/sources/wine/dlls/gdi32/dib.c:361] in gdi32 (0x0032eaa0) 6 0x7eaa05a3 StretchDIBits+0x233(hdc=0x6124, xDst=0, yDst=0, widthDst=7, heightDst=7, xSrc=0, ySrc=0, widthSrc=7, heightSrc=7, bits=0x67f97100, info=, wUsage=0, dwRop=13369376) [/sources/wine/dlls/gdi32/dib.c:295] in gdi32 (0x0032eb20) 7 0x7eb5255b LoadImageW+0x88b(hinst=0x6783, name=0x67f637f0, type=0, desiredx=7, desiredy=7, loadflags=8193) [/sources/wine/dlls/user32/cursoricon.c:2471] in user32 (0x0032ec40) 8 0x67b60b57 in opera (+0x330b57) (0x0032ecc4) I will try looking further into this, and provide any additional info I can find. -- Giuseppe "Oblomov" Bilotta
Re: DIB Engine - Mostly fixed against test suite
Well, it seems that the engine fixes some unrelated bugs too :-) Bugs 15146 and 10408, as reported by a tester. BTW In a couple of weeks all (few) remaining failing tests should be fixed. Then I'll try to optimize somehow the mixed blitting, which is the only stuff that remains slower than original. Then, last but not least, I guess I'll setup a machine for weekly packaging for ubuntu many people are asking me for autocad usage. Ciao Max
Re: DIB Engine - Mostly fixed against test suite
Am Montag, den 18.05.2009, 13:41 +0200 schrieb Massimo Del Fedele: > > Be careful with such statements. Look at bug 6519 for example. > Yep, I've seen the bug :-) > Anyways, most failures are fixed by now, also for monochrome bitmaps. > Did you test it on bug's 6519 app ? No, I don't really care. I just fixed that bug and your statement: "Color on monochrome bitmap is seldomly used anyway" sounded an alarming bell in my head. This mail was just a warning to not disregard the issue and no specific problem report. Regards, Michael Karcher
Re: DIB Engine - Mostly fixed against test suite
Michael Karcher ha scritto: Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele: 1) Some color on monochrome bitmaps here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) Be careful with such statements. Look at bug 6519 for example. Regards, Michael Karcher Yep, I've seen the bug :-) Anyways, most failures are fixed by now, also for monochrome bitmaps. Did you test it on bug's 6519 app ? Ciao Max
Re: DIB Engine - Mostly fixed against test suite
Austin English ha scritto: On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele wrote: Austin, could you please retest it against test suite ? I've ran it, but it doesn't appear to be showing up on test.winehq.org. I'll investigate why when I get a bit more time. P.S., there's now a crash in user32/cursoricon. Crash "fixed" on latest post. The fix is partial, as it depends on getting the right color table of a DIB from inside GetDIBits. That can't be done using GetDIBColorTable() as it requires the DIB to be selected into a DC, which is exactly the opposite requirement og GetDIBits. I guess I have to resort to a list of DIB <---> physical bitmaps to do it reliably, as windows doesn't bring any reliable other way to do it. Concluding : crash fixed but a couple of failures in tests/bitmap.c in addition to remaining 4. Total, 6, which is not bad :-) Ciao Max
Re: DIB Engine - Mostly fixed against test suite
Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele: > 1) Some color on monochrome bitmaps here I guess nobody knows how to do > it right. I fixed some todo wine (most) but have 2 failures which wine does > right. > Seldom used anyways, and happens only on weird palettes. I guess not ever > Microsoft knows what they did on this respect :-) Be careful with such statements. Look at bug 6519 for example. Regards, Michael Karcher signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: DIB Engine - Mostly fixed against test suite
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele wrote: > Austin, could you please retest it against test suite ? I've ran it, but it doesn't appear to be showing up on test.winehq.org. I'll investigate why when I get a bit more time. P.S., there's now a crash in user32/cursoricon. -- -Austin
Re: DIB Engine - Mostly fixed against test suite
Massimo Del Fedele wrote: There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-) Hey Max, It sounds like you're in a better position than most to write a conformance test for these missing/buggy features, since you're aware of them. That might help everyone, and also make your DIB engine more attractive since it'll be passing even more tests that current Wine may not be. Keep up the good work :) Thanks, Scott Ritchie
DIB Engine - Mostly fixed against test suite
Remaining bugs are related to : 1) Some color on monochrome bitmaps here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) 2) an AlphaBlend() call which should fail and doesn't. Here I really don't know why it should fail. Uninfluent, anyways. 3) GetDIBits on a source DIB with BPP <= 8 fails to retrieve the original DIB palette, and synthesizes a new one instead. For the moment I found no simple way to grab the palette from inside GetDIBits without maintaining a linked list of HBITMAP <--> internal bitmaps. Not worth the effort for the moment anyways. If somebody notices weird colors due to it, I'll try to fix. There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-) Austin, could you please retest it against test suite ? (code on Bug421 page) Ciao Max
Re: DIB Engine - first set of fixings agains wine test suite
Zachary Goldberg ha scritto: On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele wrote: Giuseppe Bilotta ha scritto: On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote: I started fixing failures against test suite. Most of bitmap ones are fixed, remaining are due to still stubbed funcs. Now the problem is that it fixed also most todo_wines on bitmap suite As usual, on bug 421 page for who wants to test it. I noticed that you patches are not created with git format-patch (and thus cannot be applied with git am). Which tool are you using to maintain them? Maybe you could set up a public git repository with your patches applied on top of official Wine. I use stacked git to maintaint my patches. Instructions are on bug 421 page, but I'll repeat them here : 1) Install stacked git if you don't already have it : sudo apt-get install stgit (or whathever your distro needs) 2) switch to a new branch (stgit operates on branches, not on origin) git checkout -b dibeng-max 3) init stacked git branch (needed only first time) stg init 4) import the patchset stg import -s /path/to/patchset/series 5) if you want to get rid of stgit data, just commit the patchset that's not needed if you want to continue using stgit to push/pop/rebase the patchset stg commit (this one will leave you with a standard git tree again) 6) run autoconf -- that's needed because 'configure' file is NOT included in my patchset, as it changes too much from git releases and it is usually quite big patch autoconf 7) build as usual ./configure && make depend && make 8) enable the engine before running apps export WINEDIB=ON *or* fiddle with registry, as explained on bug 421 page if you want it permanent Ciao Max Max, Would it be possible to please make a wiki page with all of this information? Theres something like 250 comments on bug 421 and its difficult to find the posts you refer to sometimes :) Thanks! -Zach Eh, sorry but I've got no time now But if some volunteer wants to do it for me is ok :-) Ciao Max
Re: DIB Engine - first set of fixings agains wine test suite
On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele wrote: > Giuseppe Bilotta ha scritto: >> >> On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote: >> >>> I started fixing failures against test suite. >>> Most of bitmap ones are fixed, remaining are due >>> to still stubbed funcs. >>> >>> Now the problem is that it fixed also most todo_wines on bitmap suite >>> >>> As usual, on bug 421 page for who wants to test it. >> >> I noticed that you patches are not created with git format-patch (and >> thus cannot be applied with git am). Which tool are you using to >> maintain them? Maybe you could set up a public git repository with >> your patches applied on top of official Wine. >> > > I use stacked git to maintaint my patches. > Instructions are on bug 421 page, but I'll repeat them here : > > 1) Install stacked git if you don't already have it : > sudo apt-get install stgit (or whathever your distro needs) > > 2) switch to a new branch (stgit operates on branches, not on origin) > git checkout -b dibeng-max > > 3) init stacked git branch (needed only first time) > stg init > > 4) import the patchset > stg import -s /path/to/patchset/series > > 5) if you want to get rid of stgit data, just commit the patchset > that's not needed if you want to continue using stgit to push/pop/rebase > the patchset > stg commit (this one will leave you with a standard git tree again) > > 6) run autoconf -- that's needed because 'configure' file is NOT included in > my > patchset, as it changes too much from git releases and it is usually quite > big patch > autoconf > > 7) build as usual > ./configure && make depend && make > > 8) enable the engine before running apps > export WINEDIB=ON > *or* > fiddle with registry, as explained on bug 421 page if you want it permanent > > Ciao > > Max > > > > Max, Would it be possible to please make a wiki page with all of this information? Theres something like 250 comments on bug 421 and its difficult to find the posts you refer to sometimes :) Thanks! -Zach
Re: DIB Engine - first set of fixings agains wine test suite
Giuseppe Bilotta ha scritto: On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote: I started fixing failures against test suite. Most of bitmap ones are fixed, remaining are due to still stubbed funcs. Now the problem is that it fixed also most todo_wines on bitmap suite As usual, on bug 421 page for who wants to test it. I noticed that you patches are not created with git format-patch (and thus cannot be applied with git am). Which tool are you using to maintain them? Maybe you could set up a public git repository with your patches applied on top of official Wine. I use stacked git to maintaint my patches. Instructions are on bug 421 page, but I'll repeat them here : 1) Install stacked git if you don't already have it : sudo apt-get install stgit (or whathever your distro needs) 2) switch to a new branch (stgit operates on branches, not on origin) git checkout -b dibeng-max 3) init stacked git branch (needed only first time) stg init 4) import the patchset stg import -s /path/to/patchset/series 5) if you want to get rid of stgit data, just commit the patchset that's not needed if you want to continue using stgit to push/pop/rebase the patchset stg commit (this one will leave you with a standard git tree again) 6) run autoconf -- that's needed because 'configure' file is NOT included in my patchset, as it changes too much from git releases and it is usually quite big patch autoconf 7) build as usual ./configure && make depend && make 8) enable the engine before running apps export WINEDIB=ON *or* fiddle with registry, as explained on bug 421 page if you want it permanent Ciao Max
Re: DIB Engine - first set of fixings agains wine test suite
On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote: > I started fixing failures against test suite. > Most of bitmap ones are fixed, remaining are due > to still stubbed funcs. > > Now the problem is that it fixed also most todo_wines on bitmap suite > > As usual, on bug 421 page for who wants to test it. I noticed that you patches are not created with git format-patch (and thus cannot be applied with git am). Which tool are you using to maintain them? Maybe you could set up a public git repository with your patches applied on top of official Wine. -- Giuseppe "Oblomov" Bilotta
DIB Engine - first set of fixings agains wine test suite
I started fixing failures against test suite. Most of bitmap ones are fixed, remaining are due to still stubbed funcs. Now the problem is that it fixed also most todo_wines on bitmap suite As usual, on bug 421 page for who wants to test it. Ciao Max
Re: DIB Engine : Almost 100% working
2009/5/12 Scott Ritchie : > Ben Klein wrote: >> >> 2009/5/12 Scott Ritchie : >>> >>> Henri Verbeet wrote: >>>> >>>> 2009/5/11 Scott Ritchie : >>>>> >>>>> Henri Verbeet wrote: >>>>>> >>>>>> 2009/5/11 Joerg Mayer : >>>>>>> >>>>>>> As I think that Alexandre has stated his preference (and I can >>>>>>> understand >>>>>>> him taking a long term view), I want to ask the packagers for the >>>>>>> distros >>>>>>> out there: Would it be OK for you to add the necessary patch into the >>>>>>> code that you distribute. Personally, that means Marcus and the >>>>>>> openSUSE >>>>>>> wine packages :-) >>>>>>> >>>>>> While distributions are of course free to do that, keep in mind that >>>>>> that would also make them responsible for supporting that code. I'm >>>>>> not sure how feasible that would be for something so close to core >>>>>> Wine functionality. >>>>>> >>>>>> >>>>> Distributions don't really "support" Wine anyway. At best we just make >>>>> a >>>>> new package every now and again. >>>>> >>>> Yes, but the point is that bugs filed against such a package are >>>> potentially invalid. (People should use git for filing bugs, but not >>>> everyone does.) >>>> >>>> >>> We already expect our users to indicate if they've done any manual >>> registry >>> changes when reporting bugs. This seems like just another instance of >>> that. >> >> But they usually don't. >> >> As the Debian package maintainer, I won't bundle the DIB engine until >> it makes it into Wine release sources. I have the same policy for any >> other patch (including my own simple, >> definitely-won't-hurt-anything-but-will-make-things-better patches) to >> assist in keeping bugzilla *and AppDB* "clean". Do we really want the >> users to submit AppDB posts that depend on who packaged the binaries? > > This might not be that bad, since the individual test report indicates their > distribution. Won't work so well for Debian where there are separate, Debian-supported packages (with recent versions if you grab them from experimental). > From my own observations of AppDB reports, when users do > things like winetricks or marking DLLs as native they tend to include that > in the report (or at least say something like "I used the winetricks > workarounds from the howto below") If we're lucky, yes :P However, some users may get confused if there's an option in the registry that works for some but not others. To eliminate confusion, we will need consensus from all packagers, and possibly some distributions that have packages separate from what's on the download page on WineHQ. At least, to *minimise* confusion, the packagers on WineHQ will need consensus. However, I suspect that AJ will object to the DIB engine going in to all packages provided by WineHQ, as this implies official support for a patchset that has been rejected upstream.
Re: DIB Engine : Almost 100% working
Ben Klein wrote: 2009/5/12 Scott Ritchie : Henri Verbeet wrote: 2009/5/11 Scott Ritchie : Henri Verbeet wrote: 2009/5/11 Joerg Mayer : As I think that Alexandre has stated his preference (and I can understand him taking a long term view), I want to ask the packagers for the distros out there: Would it be OK for you to add the necessary patch into the code that you distribute. Personally, that means Marcus and the openSUSE wine packages :-) While distributions are of course free to do that, keep in mind that that would also make them responsible for supporting that code. I'm not sure how feasible that would be for something so close to core Wine functionality. Distributions don't really "support" Wine anyway. At best we just make a new package every now and again. Yes, but the point is that bugs filed against such a package are potentially invalid. (People should use git for filing bugs, but not everyone does.) We already expect our users to indicate if they've done any manual registry changes when reporting bugs. This seems like just another instance of that. But they usually don't. As the Debian package maintainer, I won't bundle the DIB engine until it makes it into Wine release sources. I have the same policy for any other patch (including my own simple, definitely-won't-hurt-anything-but-will-make-things-better patches) to assist in keeping bugzilla *and AppDB* "clean". Do we really want the users to submit AppDB posts that depend on who packaged the binaries? This might not be that bad, since the individual test report indicates their distribution. From my own observations of AppDB reports, when users do things like winetricks or marking DLLs as native they tend to include that in the report (or at least say something like "I used the winetricks workarounds from the howto below") Thanks, Scott Ritchie
Re: DIB Engine : Almost 100% working
2009/5/12 Scott Ritchie : > Henri Verbeet wrote: >> >> 2009/5/11 Scott Ritchie : >>> >>> Henri Verbeet wrote: >>>> >>>> 2009/5/11 Joerg Mayer : >>>>> >>>>> As I think that Alexandre has stated his preference (and I can >>>>> understand >>>>> him taking a long term view), I want to ask the packagers for the >>>>> distros >>>>> out there: Would it be OK for you to add the necessary patch into the >>>>> code that you distribute. Personally, that means Marcus and the >>>>> openSUSE >>>>> wine packages :-) >>>>> >>>> While distributions are of course free to do that, keep in mind that >>>> that would also make them responsible for supporting that code. I'm >>>> not sure how feasible that would be for something so close to core >>>> Wine functionality. >>>> >>>> >>> Distributions don't really "support" Wine anyway. At best we just make a >>> new package every now and again. >>> >> Yes, but the point is that bugs filed against such a package are >> potentially invalid. (People should use git for filing bugs, but not >> everyone does.) >> >> > > We already expect our users to indicate if they've done any manual registry > changes when reporting bugs. This seems like just another instance of that. But they usually don't. As the Debian package maintainer, I won't bundle the DIB engine until it makes it into Wine release sources. I have the same policy for any other patch (including my own simple, definitely-won't-hurt-anything-but-will-make-things-better patches) to assist in keeping bugzilla *and AppDB* "clean". Do we really want the users to submit AppDB posts that depend on who packaged the binaries?
