[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 jjmckenzi...@earthlink.net To: Andrew Eikum and...@brightnightgames.com References: a71bd89a0905301414j5bd70f74y3441d367b49bc...@mail.gmail.com 1243755935.4535.1.ca...@stephan-desktop 4a22ad55.5020...@brightnightgames.com b6bb06270905311154w2b9ccb12jee6d64ea587f9...@mail.gmail.com 4a22d65a.3030...@brightnightgames.com Andrew Eikum wrote: Austin English wrote: On Sun, May 31, 2009 at 11:16 AM, Andrew and...@brightnightgames.com 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 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
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 Sun, May 31, 2009 at 11:16 AM, Andrew and...@brightnightgames.com 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
Austin English wrote: On Sun, May 31, 2009 at 11:16 AM, Andrew and...@brightnightgames.com 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 2:11 PM, Andrew Eikum and...@brightnightgames.com 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
On Sun, May 31, 2009 at 12:45 AM, Stephan Rose ker...@somrek.net 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, 2009-05-31 at 12:23 -0700, Dan Kegel wrote: On Sun, May 31, 2009 at 12:45 AM, Stephan Rose ker...@somrek.net 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
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: 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
2009/5/30 Dan Kegel d...@kegel.com: 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
On Fri, May 29, 2009 at 10:10 AM, chris ahrendt celtich...@yahoo.com 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
Re: DIB engine
On 05/29/2009 11:14 AM, Austin English wrote: On Fri, May 29, 2009 at 10:10 AM, chris ahrendtceltich...@yahoo.com 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:50 AM, chris ahrendt celtich...@yahoo.com 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
2009/5/29 Austin English austinengl...@gmail.com: On Fri, May 29, 2009 at 10:50 AM, chris ahrendt celtich...@yahoo.com 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
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
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. 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
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
2009/5/30 chris ahrendt celtich...@yahoo.com: 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 ker...@somrek.net: 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
Stephan Rose ker...@somrek.net 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 : passing all tests
2009/5/28 John Klehm xixsimplicity...@gmail.com: On Wed, May 27, 2009 at 8:47 PM, James McKenzie jjmckenzi...@earthlink.net wrote: So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival. I'm not sure why it's a strange thing that the people that spend the most time with wine code have the most patches committed. To try and make an accusation that the project is restricted to paid peoples is both false and pointlessly inflammatory. If there was a glut of manpower there'd be plenty of time to give full reviews of every patch. As it is everyone gives the time they can. It also depends where your experience lies. I am predominantly a UI developer, and having spent a long time writing UI code that is where I feel most comfortable working in. That does not mean that I know the behaviour of every Windows control inside and out, just that this is an area I feel capable of working on. I am in awe of what the DirectX developers have done. I doubt I would be able to work in that area. Especially as I don't understand either DirectX or OpenGL. Same goes for the GDI/DIB engine code, the crypto code or a hundred other areas of the Windows API that Wine implements. To work on an area of Wine, you need to have a deep understanding of how the Windows API works. For some areas (such as implementing the different Windows controls), you can do that purely through the Windows API. For other areas, you also need an understanding of how Linux/BSD/Mac/OpenSolaris/others implement that domain. Wine has some very talented developers working on it. The problem comes when you have some functionality (like the DIB engine) that cuts across a large number of areas and requires a very deep understanding of both Windows and Linux/etc to grasp what needs to be done. And yes, that requires a lot of time and effort. - Reece
Re: DIB Engine : passing all tests
2009/5/27 Massimo Del Fedele m...@veneto.com: 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
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
On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele m...@veneto.com wrote: IMHO, and really in my opinion, loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32. It seems to me the best course is keep developing it outside of the tree until the remaining glitches are resolved and then try to resubmit it by moving in to gdi32. At least if Alexandre still wants to reject it due to remaining design issues, we have a good enough alternative. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
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 winehac...@gmail.com wrote: On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele m...@veneto.com wrote: IMHO, and really in my opinion, loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32. It seems to me the best course is keep developing it outside of the tree until the remaining glitches are resolved and then try to resubmit it by moving in to gdi32. At least if Alexandre still wants to reject it due to remaining design issues, we have a good enough alternative. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo -- Jerome Leclanche
Re: DIB Engine : passing all tests
On Thu, May 28, 2009 at 6:58 PM, Jerome Leclanche adys...@gmail.com wrote: Hi Max, From what I understand, the problem is not your design. I don't want to put words in anyone's mouth, but to me it seems you and AJ agree on the final goal; Alexandre just doesn't want the intermediary step in the master tree (there could be many reasons for this). As you said, starting the move to gdi32 right now would be a huge waste of time (in maintenance and more), and prone to hell-knows how many regressions. You should get the DIB engine uploaded to its own repo or wine-hacks (http://repo.or.cz/w/wine/hacks.git). It's also been mentioned, but getting some documentation up and running on the wiki would be of great help. Maybe the authors of the previous DIB engine attempts could also give a shot at helping with that. People will also want (need) to know what they should test, how to test it, where to give feedback, what's still in the works, ... You've done a great job so far, here's hoping it gets sorted :) J On Thu, May 28, 2009 at 10:46 PM, Steven Edwards winehac...@gmail.com wrote: On Thu, May 28, 2009 at 2:20 PM, Massimo Del Fedele m...@veneto.com wrote: IMHO, and really in my opinion, loosing time to integrate it inside gdi32 whithout proper guidelines would be crazy. I mean, I'd never do it :-) The intermediate step was made (among other reasons) to check if the upcoming driver had the chance to be accepted. Moving it *now* inside gdi32 would mean a big loss of time with almost no hopes to see it in mainstream, added to the above effort of keeping it in sync with changing gdi32. OTOH, if winedib would be embedded as-is or with some minor mods, I could od course take the job of moving it stepwise into gdi32. It seems to me the best course is keep developing it outside of the tree until the remaining glitches are resolved and then try to resubmit it by moving in to gdi32. At least if Alexandre still wants to reject it due to remaining design issues, we have a good enough alternative. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo -- Jerome Leclanche I completely agree with Jerome, and would like to add that tests of the DIB engine would probably be accepted into the tree. Since Max knows the finer notches of the DIB engine, taking the time to write some tests would seem to be a good idea - both to speed up the future migration and to make sure we're not missing any quirks. It may also help pinpoint certain bugs within the implementation. Mike.
Re: DIB Engine : passing all tests
Dmitry Timoshkov ha scritto: Massimo Del Fedele m...@veneto.com wrote: The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a transient phase, at the end all dib processing should go inside gdi32. Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called GDI font (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new font driver, so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing. I begin to repeat stuffs too often lately. As I already wrote, *I know* and *I agree* that DIB should belong to GDI32. The proposed driver is a working step to that final goal. Point. Max
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
On Wed, May 27, 2009 at 2:11 AM, Massimo Del Fedele m...@veneto.com wrote: Strange enough, as the consensus on Huw's design was great, and it used a *real* external driver, and *not* an intermediate one as mine. But I start thinking that the requirements and consensus are very fluid and moving matters, lately. Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point. Not directed toward you, Massimo, but others: Keep in mind, Massimo has sent patches dozens of times, along with explanations/critiques. Unless you have something *NEW* to add (check the archives), please refrain from commenting since in waste a lot of time. -- -Austin
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 10:26 AM, Vit Hrachovy vit.hrach...@sandbox.cz wrote: Massimo Del Fedele wrote: Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point. Hi Max, would it be possible to craft a wikipage on Wine Wiki, that would encompass * official DIB implementation requirements * high level description of Huw's solution * description of Your solution incl. proposed integration plan It would ease the orientation, prevent repeating the same stuff again and again and it could also serve as a solid base for further discussion about DIB integration requirements. Regards Hark I have asked Alexandre about it but it wasn't really an option. Even for Huw writing a full dib engine (if he resumed his current code) would take five months or so full time. Filling in the 'easy' bits (which Alexandre considers most of the things done so far) is not that much work (the easy bits are the software drawing functions). Roderick
Re: DIB Engine : passing all tests
2009/5/27 Roderick Colenbrander thunderbir...@gmail.com On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy vit.hrach...@sandbox.cz wrote: would it be possible to craft a wikipage on Wine Wiki, that would encompass * official DIB implementation requirements * high level description of Huw's solution * description of Your solution incl. proposed integration plan I have asked Alexandre about it but it wasn't really an option. Even for Huw writing a full dib engine (if he resumed his current code) would take five months or so full time. Filling in the 'easy' bits (which Alexandre considers most of the things done so far) is not that much work (the easy bits are the software drawing functions). I'm not sure I understand this answer, as all but the first line doesn't seem to relate to the question. Are you saying that you have been told that making the documentation Vit described wasn't an option? -- Chris
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
On Wed, May 27, 2009 at 8:47 PM, James McKenzie jjmckenzi...@earthlink.net wrote: So what say all, shall we try to make coding better and as Max stated, fun. Most of the folks here do not support this project for a living and we should not restrict this project to those who do. However, it appears that a vast majority of the patches are coming from those who either are long time Wine 'hackers' or those whose living depends on this project's survival. I'm not sure why it's a strange thing that the people that spend the most time with wine code have the most patches committed. To try and make an accusation that the project is restricted to paid peoples is both false and pointlessly inflammatory. If there was a glut of manpower there'd be plenty of time to give full reviews of every patch. As it is everyone gives the time they can. --John Klehm
Re: DIB Engine : passing all tests
Massimo Del Fedele m...@veneto.com writes: About point 4, which, I guess, is the most important for you, the next step would be to make a winex11-2.drv on which DIB processing would be stripped away, and with added DDB buffering of DIBs and mixed blit operations. That driver could be connected to (and tested with) winedib.drv, always as an option in registry/environment. Once ready and stable enough it should be made permanently enabled and remaining part of winedib.drv could be merged inside gdi32; that could also be made stepwise. Of course this design would mean some duplication of code in gdi32 and winex11.drv, at least if we don't want to change something in driver function tables which would be the best solution if it's not imposed by Microsoft behaviour (I didn't check that one, nor I think to do it for the moment). A simple GetLine() * PutLine() that do translation between 32 bit RGBA -- DDB inside winex11.drv and callable by gdi32 would of course avoid all code duplication needed for mixed blitting, keeping needed speed. That addition would be trivial. I think my design has some advantages and some disadvantages to other ones, but it's superior to the double pointer approach taken before, for reasons already explained. The main disadvantage, maybe the only one, is to have for some time 2 different drivers in wine. but OTOH it allows deep testing without breaking anything. One of the main problems I see is that your design is based on the premise that there's only one graphics driver, the X11 driver. That's clearly not the case, DIBs can be used with any driver (and with multiple drivers at the same time). This is also why you can't have the DIB driver decide on when to forward/not forward to the X11 driver, it should go in the other direction. I'm also very skeptical about mirroring DIBs with a DDB. But even if you do this that should be a purely internal x11drv decision, the DIB engine shouldn't have any notion about this at all. This means you can't expose DIB-DDB conversion routines, DDBs are entirely up to the graphics driver. -- Alexandre Julliard julli...@winehq.org
Re: DIB Engine : passing all tests
Chris Morgan chmor...@gmail.com writes: Wouldn't a review of the proposed dib engine be useful? One that included concerns, things that needed to be changed etc? Everyone involved seems to be asking for leadership and guidance about how to proceed, wouldn't a thorough review of the proposed design give direction towards an acceptable design? Of course, but a thorough review takes time, lots of time. If you want Huw or myself to invest that kind of time, you have to demonstrate that it's worth it. That was my point about first establishing a track record with simpler stuff. The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff. -- Alexandre Julliard julli...@winehq.org
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
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
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
Massimo Del Fedele m...@veneto.com wrote: The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a transient phase, at the end all dib processing should go inside gdi32. Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called GDI font (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new font driver, so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing. -- Dmitry.
Re: DIB Engine : passing all tests
2009/5/27 Dmitry Timoshkov dmi...@codeweavers.com: Massimo Del Fedele m...@veneto.com wrote: The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a transient phase, at the end all dib processing should go inside gdi32. Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called GDI font (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new font driver, so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing. From what I gather, the desired architecture is to integrate DIB engine into GDI32 wherever applicable (so the current DIB-related methods will be reimplemented with a possibly optional DIB engine). This also seems to be in keeping with Max's end-goal architecture - to integrate with GDI32. A little while ago I was trying to run an app that uses Win16 DIB.DRV (I forget which app it was). My research indicated that although DIB.DRV was an actual driver (similar in architecture to Max's proposed DIB engine) in Win16 systems, in Windows 95 the functionality was rolled into GDI. For my app, this means that (in theory) exposing appropriate, existing DIB functions to my Win16 app in the form of a virtual DIB.DRV should work. For Max's engine, we're looking at diverging from Microsoft's modern architecture and switching back to something that was good enough 25 years ago. We all know AJ wants things to be done the right way the first time. I agree with this policy, because it makes for more maintainable code, less duplication, etc. Wine's patch acceptance policy specifically prohibits hack it until it works, then worry about it later style programming, and the consensus of devs seems to be that adding a new DIB *driver* as an intermediary between GDI32 and hardware drivers is the wrong way to go about things.
Re: DIB Engine : passing all tests
On Sun, May 24, 2009 at 10:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: That's ugly. Did you attempt to type in something in the Document area? I've disabled all my Quartz hacks, the only thing sort of non-standard I have is my custom FreeType with patented engine enabled and support for SubPixel rendering turned on. Now that I think about it, that could be a problem. I'll try another round of testing with that disabled next. Yes, it is MUCH faster rendering and scrolling and the like but there are minor glitches with the font placement in the document area. Notice how the word support and deployment overlap with the dib engine and how the lines alternate color? The speed difference for editing is like night and day. The header and footers for the document body containing images renders fine. Installers such as ie6setup and msxml3 embedded images don't render properly, I'll try to upload images for that as well in the morning. Bugzilla seems to be running quite slow so I can't upload the images there. Comparison screenshots for Word are here http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_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 ha scritto: On Sun, May 24, 2009 at 10:19 PM, James McKenzie jjmckenzi...@earthlink.net wrote: That's ugly. Did you attempt to type in something in the Document area? I've disabled all my Quartz hacks, the only thing sort of non-standard I have is my custom FreeType with patented engine enabled and support for SubPixel rendering turned on. Now that I think about it, that could be a problem. I'll try another round of testing with that disabled next. Yes, it is MUCH faster rendering and scrolling and the like but there are minor glitches with the font placement in the document area. Notice how the word support and deployment overlap with the dib engine and how the lines alternate color? The speed difference for editing is like night and day. The header and footers for the document body containing images renders fine. Installers such as ie6setup and msxml3 embedded images don't render properly, I'll try to upload images for that as well in the morning. Bugzilla seems to be running quite slow so I can't upload the images there. Comparison screenshots for Word are here http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_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 12:04 PM, Chris Howe mrmess...@gmail.com wrote: 2009/5/24 Massimo Del Fedele m...@veneto.com Sorry to sound like a stuck record but the Wine website still lists write a DIB engine as a requirement, and every time someone does, the patches dissapear down a hole because they're not right. Someone document what would be right, or take write a DIB engine off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions. Agreed. I would be willing to invest some time this summer in a DIB engine but it's impossible because of this. A wiki page describing the right design and what is needed in which component would be a great start. Maybe a goal for next WineConf? I understand people are working on other important issues and that's much appreciated, but it's frustrating that so much valuable time has been spent on this (discussions and code) for years and see all attempts hit the same brick wall.
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
Jan de Mooij jandemo...@gmail.com writes: On Sun, May 24, 2009 at 12:04 PM, Chris Howe mrmess...@gmail.com wrote: 2009/5/24 Massimo Del Fedele m...@veneto.com Sorry to sound like a stuck record but the Wine website still lists write a DIB engine as a requirement, and every time someone does, the patches dissapear down a hole because they're not right. Someone document what would be right, or take write a DIB engine off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions. Agreed. I would be willing to invest some time this summer in a DIB engine but it's impossible because of this. A wiki page describing the right design and what is needed in which component would be a great start. Maybe a goal for next WineConf? Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype, and then convince people (especially Huw and myself) that your design is good, that you know what you are doing, that you have anticipated the common objections and have good answers for them, that you are willing to make requested changes, that you have good test cases, etc. Showing that it more or less works on a couple of apps, or that it passes the (very few) existing gdi32 tests, is of course necessary, but by no means enough. If you want to tackle this, it will also help to have a good track record in getting simpler patches in first. Once all of this is done and the proper design is in place in the tree, then there might be a number of fill-in-the-blanks tasks to implement the less common graphics calls that would probably be stubbed out in the first version. But we are nowhere near that point yet. -- Alexandre Julliard julli...@winehq.org
Re: DIB Engine : passing all tests
On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julli...@winehq.org wrote: Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype, Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet anticipated common objections etc.?
Re: DIB Engine : passing all tests
Zachary Goldberg zg...@bluesata.com writes: On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julli...@winehq.org wrote: Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype, Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet anticipated common objections etc.? Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far. -- Alexandre Julliard julli...@winehq.org
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
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
On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard julli...@winehq.org wrote: Zachary Goldberg zg...@bluesata.com writes: On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julli...@winehq.org wrote: Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype, Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet anticipated common objections etc.? Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far. -- Alexandre Julliard 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
On Mon, May 25, 2009 at 9:32 PM, Chris Morgan chmor...@gmail.com wrote: On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard julli...@winehq.org wrote: Zachary Goldberg zg...@bluesata.com writes: On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard julli...@winehq.org wrote: Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype, Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet anticipated common objections etc.? Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far. -- Alexandre Julliard 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 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
Ben Klein ha scritto: 2009/5/24 Massimo Del Fedele m...@veneto.com: Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele m...@veneto.com wrote: I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some false positive signaled by tests. Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-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
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
2009/5/24 Massimo Del Fedele m...@veneto.com I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet? Nope, and I think they will not be solved soon. Not by me, anyways. I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an alternative experimental driver in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever. I assume all this took place on IRC because unless I missed it, Alexandre hasn't deigned to comment on here about what the right architectural solution would be. Sorry to sound like a stuck record but the Wine website still lists write a DIB engine as a requirement, and every time someone does, the patches dissapear down a hole because they're not right. Someone document what would be right, or take write a DIB engine off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions. -- Chris
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
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
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: 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
2009/5/25 Massimo Del Fedele m...@veneto.com: André Hentschel ha scritto: I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes To make this work and be as portable as possible, you'd need to produce pure win32 DLLs (not ELF/PE hybrid .dll.so files). You would then only need to distribute win32 and win64 variants, and not need to worry about all the different kernels/libc's Wine is capable of running on. :)
Re: DIB Engine : passing all tests
On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele m...@veneto.com wrote: André Hentschel ha scritto: No idea on what will happen with Mac or other unixes I am attempting a Mac build now. As with the rest of the discussion, It would be nice if we could produce a PE version using something like cygwin with X11 headers and the -mno-cygwin switch but I don't know if this would really work. If did then it should work on everything. Thanks -- Steven Edwards 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 11:06 AM, Massimo Del Fedele m...@veneto.com wrote: André Hentschel ha scritto: No idea on what will happen with Mac or other unixes I am attempting a Mac build now. As with the rest of the discussion, It would be nice if we could produce a PE version using something like cygwin with X11 headers and the -mno-cygwin switch but I don't know if this would really work. If did then it should work on everything. Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX. James McKenzie
Re: DIB Engine : passing all tests
Steven Edwards wrote: On Sun, May 24, 2009 at 9:23 PM, James McKenzie jjmckenzi...@earthlink.net wrote: Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX. I think I am using the latest patch, its dibeng_max.zip thats got the 1-10 patches. There are some major graphical glitches, though it could be related to me having Quartz Extreme and Quartz2d enabled on unsupported hardware. It does seem much faster though. Sorry I don't have time right now to do a complete report. I'll try to upload information to bugzilla in the morning after I make my environment a little more sane. That's ugly. Did you attempt to type in something in the Document area? I don't have the time tonight to attempt to build and run the DIB stuff to see what it does to the games and other programs that I work with. Maybe, tomorrow afternoon after my bicycle ride. James McKenzie
Re: DIB Engine : passing all tests
On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele m...@veneto.com wrote: I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some false positive signaled by tests. Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-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
Re: DIB Engine : passing all tests
Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele m...@veneto.com wrote: I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some false positive signaled by tests. Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-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
2009/5/24 Massimo Del Fedele m...@veneto.com: Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele m...@veneto.com wrote: I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some false positive signaled by tests. Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-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 - 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=register EDI not in topmost frame, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=register EDI not in topmost frame, startscan=register ESI not in topmost frame, 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=register EDI not in topmost frame, 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
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=register EDI not in topmost frame, copyPixels=0) [/sources/wine/dlls/winedib.drv/dibdrvbitmap.c:421] in winedib (0x0032e910) 4 0x7e8c257d DIBDRV_SetDIBits+0x1ed(physDev=0x19f478, hbitmap=register EDI not in topmost frame, startscan=register ESI not in topmost frame, 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=register EDI not in topmost frame, 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
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
Austin English ha scritto: On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele m...@veneto.com 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
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
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
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
Re: DIB Engine - Mostly fixed against test suite
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele m...@veneto.com 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 - 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
Re: DIB Engine - first set of fixings agains wine test suite
On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele m...@veneto.com 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
Zachary Goldberg ha scritto: On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele m...@veneto.com 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 : Almost 100% working
Hello (mostly wine package maintainers), On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: James McKenzie ha scritto: Good work. Have you started to think about how to get this into Wine where AJ will approve? Ah, I'm not very optimistic that it'll ever enter on wine tree :-) Nor have I time to adopt the trial and error way up to it's approved. The easiest way I see by now is to add it to wine drivers as an alternative driver in parallel to X11 one. That could be done in less then 5 minutes and with no regressions :-) So from the end users point of view Alexandre is refusing this solution which is much better than what exists now into the official wine tree. To solve this problem from an end users view, I see two approaches: 1) Alexandre is willing to allow that code into the wine repository, so it can be maintained in sync with the existing wine code (it is my understanding that the modifications to existing code are quite small) and leave it to the user to choose which code to use. 2) We use the same solution that is used by the linux kernel developers: Keep the official source clean but add any (dearly wanted/needed) features as part of the distribution kernel. 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 :-) ciao Joerg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
Re: DIB Engine : Almost 100% working
2009/5/11 Joerg Mayer jma...@loplof.de Hello (mostly wine package maintainers), On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: James McKenzie ha scritto: Good work. Have you started to think about how to get this into Wine where AJ will approve? Ah, I'm not very optimistic that it'll ever enter on wine tree :-) Nor have I time to adopt the trial and error way up to it's approved. So from the end users point of view Alexandre is refusing this solution which is much better than what exists now into the official wine tree. Going to make that request for official (Alexandre-approved) documentation of the right way to go up somewhere, one more time. Its ludicrous that there's a solution this good that's wrong, and there's no roadmap for making a better one. -- Chris
Re: DIB Engine : Almost 100% working
On Mon, May 11, 2009 at 6:07 AM, Chris Howe mrmess...@gmail.com wrote: 2009/5/11 Joerg Mayer jma...@loplof.de Hello (mostly wine package maintainers), On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: James McKenzie ha scritto: Good work. Have you started to think about how to get this into Wine where AJ will approve? Ah, I'm not very optimistic that it'll ever enter on wine tree :-) Nor have I time to adopt the trial and error way up to it's approved. So from the end users point of view Alexandre is refusing this solution which is much better than what exists now into the official wine tree. Going to make that request for official (Alexandre-approved) documentation of the right way to go up somewhere, one more time. Its ludicrous that there's a solution this good that's wrong, and there's no roadmap for making a better one. It would still take a lot of time to write that documentation. Time is money, and AJ/Huw are both busy people. Unless someone sponsors it, it's on the back burner, since it's not for sure that it would even help popular applications. Not the answer most people want, but the truth isn't always comfortable. -- -Austin
Re: DIB Engine : Almost 100% working
2009/5/11 Joerg Mayer jma...@loplof.de: 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.
Re: DIB Engine : Almost 100% working
On Mon, May 11, 2009 at 6:20 AM, Henri Verbeet hverb...@gmail.com wrote: 2009/5/11 Joerg Mayer jma...@loplof.de: 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. Perhaps a wine-experimental branch, with applicable warnings? Getting a bunch of people to test it may give us good data on how much it improves things, which is currently lacking. -- -Austin
Re: DIB Engine : Almost 100% working
Joerg Mayer ha scritto: So from the end users point of view Alexandre is refusing this solution which is much better than what exists now into the official wine tree. Ah, wait it's not much better, is an alternative. As it is now, it gives speed improvement for some apps, and probably slowdowns for others. The slow downs are because of mixed bitmap blitting, which could be indeed solved. So, if your app does *many* dib drawing and few mixed blits, the speed can improve by high factors; the other way around it can decrease. It has also probably still bugs and for sure some primitives (rarely used) that are still not coded, as circle/ellipse/roundrect, for example. Those are trivial to add, but I still didn't need them To solve this problem from an end users view, I see two approaches: 1) Alexandre is willing to allow that code into the wine repository, so it can be maintained in sync with the existing wine code (it is my understanding that the modifications to existing code are quite small) and leave it to the user to choose which code to use. I'd agree with that one. adding an optional driver could do no harm, and would be enabled just on user request. The needed core code modifications are really really small, just few lines on a c file that (afaik) is not being modified since long time. It could even be done *without* any modification, but that would be much less comfortable for end-users, as they should fiddle with registry entries. 2) We use the same solution that is used by the linux kernel developers: Keep the official source clean but add any (dearly wanted/needed) features as part of the distribution kernel. That would mean maintain another repo in sync with the main one, not too hard job but I couldn't do it myself really no time. 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 :-) That one could be a nice solution, but I see it quite unlikely to happen. Usually packagers prefer the official stuffs. ciao Max
Re: DIB Engine : Almost 100% working
Henri Verbeet ha scritto: 2009/5/11 Joerg Mayer jma...@loplof.de: 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. As I told before, the engine almost doesn't touch wine core. It just add an intermediate layer between gdi32 and winex11.drv to handle DIBs. If not enabled, it can't simply harm anything, gdi32 will take the usual way through winex11. And, last but not least, the drivers *needs* to be explicitely enabled by end user if not, it's like it wouldn't exist. There's nothing to maintain in wine related do the engine, nor the way around. The engine as it is should be applicable to any future wine version, as lon as it doesn't change hardly the driver's function tables or driver loading in dlls/gdi32/driver.c, which is *very* unlikely to happen. Max
Re: DIB Engine : Almost 100% working
Austin English ha scritto: Perhaps a wine-experimental branch, with applicable warnings? Getting a bunch of people to test it may give us good data on how much it improves things, which is currently lacking. That one should be maintained too not a difficult task but a time consuming one. Still I think that the better way should be to include as an optional component in main tree. Max
Re: DIB Engine : Almost 100% working
On Mon, May 11, 2009 at 6:39 AM, Massimo Del Fedele m...@veneto.com wrote: Austin English ha scritto: Perhaps a wine-experimental branch, with applicable warnings? Getting a bunch of people to test it may give us good data on how much it improves things, which is currently lacking. That one should be maintained too not a difficult task but a time consuming one. Still I think that the better way should be to include as an optional component in main tree. I meant for distributions. E.g., there is already, for many: wine-stable wine-devel could add: wine-experimental I'm not suggesting an additional branch for winehq.org. AJ is busy enough as is ;-). Besides, there's already http://repo.or.cz/w/wine/hacks.git for that. -- -Austin
Re: DIB Engine : Almost 100% working
On Mon, May 11, 2009 at 12:56:28PM +0200, Joerg Mayer wrote: Hello (mostly wine package maintainers), On Sun, May 10, 2009 at 05:07:55PM +0200, Massimo Del Fedele wrote: James McKenzie ha scritto: Good work. Have you started to think about how to get this into Wine where AJ will approve? Ah, I'm not very optimistic that it'll ever enter on wine tree :-) Nor have I time to adopt the trial and error way up to it's approved. The easiest way I see by now is to add it to wine drivers as an alternative driver in parallel to X11 one. That could be done in less then 5 minutes and with no regressions :-) So from the end users point of view Alexandre is refusing this solution which is much better than what exists now into the official wine tree. To solve this problem from an end users view, I see two approaches: 1) Alexandre is willing to allow that code into the wine repository, so it can be maintained in sync with the existing wine code (it is my understanding that the modifications to existing code are quite small) and leave it to the user to choose which code to use. 2) We use the same solution that is used by the linux kernel developers: Keep the official source clean but add any (dearly wanted/needed) features as part of the distribution kernel. The distribution these days only accept stuff that has chances to be upstream. Keeping it in a parallel repo forever will not fly. Ciao, Marcus
Re: DIB Engine : Almost 100% working
Austin English ha scritto: On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele m...@veneto.com wrote: Massimo Del Fedele ha scritto: Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max fixed also last (hopefully) color format error, now some games, also D3D and Opengl ones work perfectly. Ciao Max FWIW, for those interested, I've added the DIB engine to my daily test runs. First result is here: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904-dibengine/report.html and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904/report.html (everything passes on my machine, aside from the known spurious test results). Looks like there's some bugs to fix in ddraw:visual, gdi32:bitmap (1317!), and gdi32:palette. So not quite ready yet (architecture designs aside). Ah, yep swapped colors in pixels. I fixed that everywhere but not on getpixel :-) I'll fix it later and I'll look to other (few) failures. I've seen some stuffs passed on todo, also. Max
Re: DIB Engine : Almost 100% working
On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele m...@veneto.com wrote: Massimo Del Fedele ha scritto: Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max fixed also last (hopefully) color format error, now some games, also D3D and Opengl ones work perfectly. Ciao Max FWIW, for those interested, I've added the DIB engine to my daily test runs. First result is here: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904-dibengine/report.html and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904/report.html (everything passes on my machine, aside from the known spurious test results). Looks like there's some bugs to fix in ddraw:visual, gdi32:bitmap (1317!), and gdi32:palette. So not quite ready yet (architecture designs aside). -- -Austin
Re: DIB Engine : Almost 100% working
Jeremy White wrote: Reece Dunn wrote: Also, doesn't CodeWeavers have the ability to pledge for features (such as DirectX) as well as specific applications? Well, kinda sorta, but not really. It's on our todo list and has been for a long time. I think Roderick summarized the issue from our perspective correctly. Everyone wishes it will be a magic bullet, so we all get excited about it. From Massimo's report, his DIB engine looks like it fixes a few issues on some games - like Age of Empires 2 - and has some speedups there. Not sure how much of a benefit this is going to be overall. But in practice, it helps very few applications. Improving gdiplus (an easier task), we have found to have far more dramatic benefits. I understand this approach. The DIB engine is not a trivial, or isolated piece of functionality, to develop. There are some things I'd be interested in seeing: 1. how this affects double-buffering performance (which a lot of applications make use of, as well as the common controls), which uses DIBs to draw the data off-screen; 2. how this affects theme performance (the repainting of winecfg with the Gem theme is glacially slow); 3. whether this will support alpha blending (useful for themes that support it - such as is likely to be used to provide better integration look and feel - as well as the Wine icon refresh that was being looked at). I wonder if there are any media players or video editing applications that would benefit? Anyway, I'll hopefully get around to do some testing on the DIB engine at some point to test these out. - Reece
Re: DIB Engine : Almost 100% working
Henri Verbeet wrote: 2009/5/11 Joerg Mayer jma...@loplof.de: 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. As a packager, as long as Massimo is willing to keep the patches applying to the latest version and user-optional to enable, I'd be willing to bundle em. I'm normally averse to keeping deltas with Alexandre's main branch other than backports, but this one is specifically written to not do anything unless manually enabled. Thanks, Scott Ritchie
Re: DIB Engine : Almost 100% working
Massimo Del Fedele wrote: Austin English ha scritto: FWIW, for those interested, I've added the DIB engine to my daily test runs. First result is here: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904-dibengine/report.html and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae-ub904/report.html (everything passes on my machine, aside from the known spurious test results). Looks like there's some bugs to fix in ddraw:visual, gdi32:bitmap (1317!), and gdi32:palette. So not quite ready yet (architecture designs aside). Ah, yep swapped colors in pixels. I fixed that everywhere but not on getpixel :-) I'll fix it later and I'll look to other (few) failures. I've seen some stuffs passed on todo, also. 3 cheers for the test suite! This is, right here, a good handful of bugs completely prevented by it. I'm curious how much more common findings like this are getting as Winetest has grown in sophistication. Thanks, Scott Ritchie
Re: DIB Engine : Almost 100% working
2009/5/11 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Joerg Mayer jma...@loplof.de: 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.)
Re: DIB Engine : Almost 100% working
Scott Ritchie ha scritto: As a packager, as long as Massimo is willing to keep the patches applying to the latest version and user-optional to enable, I'd be willing to bundle em. I'm normally averse to keeping deltas with Alexandre's main branch other than backports, but this one is specifically written to not do anything unless manually enabled. Well, the engine should apply to any next git, as long as there are no changes to driver's function tables (unlikely), to gdifont struct (less unlikely, but should not happen soon...) and to dlls/gdi32/driver.c (also unlikely, as it has just code to load drivers). That was one of the 2 reasons of the new approach... to not to have to rebase it manually each week :-) BTW, about the bugs spotted by testsuite, I'm looking at them just now, mostly are just GetPixel() swapped colors, I got rid of more than an half with a single patch and I guess they'll mostly disappear in short time. Ciao Max
Re: DIB Engine : Almost 100% working
Henri Verbeet wrote: 2009/5/11 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Joerg Mayer jma...@loplof.de: 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. Thanks, Scott Ritchie
Re: DIB Engine : Almost 100% working
2009/5/12 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Joerg Mayer jma...@loplof.de: 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?
Re: DIB Engine : Almost 100% working
Ben Klein wrote: 2009/5/12 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Joerg Mayer jma...@loplof.de: 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 sc...@open-vote.org: Ben Klein wrote: 2009/5/12 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Scott Ritchie sc...@open-vote.org: Henri Verbeet wrote: 2009/5/11 Joerg Mayer jma...@loplof.de: 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.
