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
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
2009/5/10 Massimo Del Fedele max@veneto.com:
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
Which games are concerned? Also eMule here is slow when the window is resized, would this DIB engine fix that or am i wrong?
2009/5/10 Warren Dumortier nwarrenfl@gmail.com
2009/5/10 Massimo Del Fedele max@veneto.com:
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
Which games are concerned? Also eMule here is slow when the window is resized, would this DIB engine fix that or am i wrong?
arx fatalis and age of empires 2 among others.
Warren Dumortier ha scritto:
2009/5/10 Massimo Del Fedele max@veneto.com:
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
Which games are concerned? Also eMule here is slow when the window is resized, would this DIB engine fix that or am i wrong?
Well, I'm not a big game player, so I don't know how many games would benefit of it. I tested Age of Empires, menus with many texts are very fast now. Arx Fatalis works, but I didn't make comparaisons.
On apps sides: Autocad works like a charm, tested on 2005 and 2008. MS Messenger 7.5 works I didn't test Emule because (IMHO, of course) it's a nonsense to use an app for which there's a perfect counterpart on Linux
Ciao
Max
Massimo Del Fedele wrote:
Warren Dumortier ha scritto:
2009/5/10 Massimo Del Fedele max@veneto.com:
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
Which games are concerned? Also eMule here is slow when the window is resized, would this DIB engine fix that or am i wrong?
Well, I'm not a big game player, so I don't know how many games would benefit of it.
Max:
Good work. Have you started to think about how to get this into Wine where AJ will approve?
James McKenzie
James McKenzie ha scritto:
Good work. Have you started to think about how to get this into Wine where AJ will approve?
James McKenzie
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 :-)
As I said before, to include it as replacement of actual driver would mean to make an half rewrite of both gdi32 and winex11. BTW, my engine has still space for a 3 optimizations that could speed it up even a lot more :
1) Font caching - shouldn't be too difficult 2) Access DDB directly for blit - not too difficult, and could bring a speed gain of 100% on mixed DDB/DIB operations 3) xxxBlt are not very optimized .... I would expect another 50-100% speed gain on blitting with few codelines more.
Ciao
Max
On Sun, May 10, 2009 at 5:07 PM, Massimo Del Fedele max@veneto.com wrote:
James McKenzie ha scritto:
Good work. Have you started to think about how to get this into Wine where AJ will approve?
James McKenzie
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 :-)
As I said before, to include it as replacement of actual driver would mean to make an half rewrite of both gdi32 and winex11. BTW, my engine has still space for a 3 optimizations that could speed it up even a lot more :
- Font caching - shouldn't be too difficult
- Access DDB directly for blit - not too difficult, and could bring
a speed gain of 100% on mixed DDB/DIB operations 3) xxxBlt are not very optimized .... I would expect another 50-100% speed gain on blitting with few codelines more.
Ciao
Max
Unfortunately getting this code into Wine is not really possible (Alexandre would like to see Huw finishing the design and all the work but no time has been assigned to him for this) BUT I think work on this DIB engine even if it won't make it in Wine isn't wasted. This DIB engine even if not correct shows us what apps can benefit and by how much from the dib engine (before we only had guesses). If running photoshop on Wine is significantly faster using the DIB engine (it might be useful to do tests for that, there are ways to benchmark photoshop) Codeweavers might work on it.
Roderick
Roderick Colenbrander ha scritto:
Unfortunately getting this code into Wine is not really possible (Alexandre would like to see Huw finishing the design and all the work but no time has been assigned to him for this) BUT I think work on this DIB engine even if it won't make it in Wine isn't wasted. This DIB engine even if not correct shows us what apps can benefit and by how much from the dib engine (before we only had guesses). If running photoshop on Wine is significantly faster using the DIB engine (it might be useful to do tests for that, there are ways to benchmark photoshop) Codeweavers might work on it.
Roderick
I'm (and not just me, afaik....) still very, very but really very curious to know *which* would be the "correct" design.... BTW, I made my design because I needed it, and I'm happy if it'll be useful for some other people, quite probable stuff having seen the amount of words wasted about the subject from year 2002. Anyways, if instead of having it as an "alternative" solution inside wine tree (which would make stuffs easier for people needing it, for example cad users) we want to let it hanging on bug 421's page hoping to have the "right" solution in a bit less than another 7 years, ok :-)
Max
On Sun, May 10, 2009 at 8:03 PM, Massimo Del Fedele max@veneto.com wrote:
Roderick Colenbrander ha scritto:
Unfortunately getting this code into Wine is not really possible (Alexandre would like to see Huw finishing the design and all the work but no time has been assigned to him for this) BUT I think work on this DIB engine even if it won't make it in Wine isn't wasted. This DIB engine even if not correct shows us what apps can benefit and by how much from the dib engine (before we only had guesses). If running photoshop on Wine is significantly faster using the DIB engine (it might be useful to do tests for that, there are ways to benchmark photoshop) Codeweavers might work on it.
Roderick
I'm (and not just me, afaik....) still very, very but really very curious to know *which* would be the "correct" design.... BTW, I made my design because I needed it, and I'm happy if it'll be useful for some other people, quite probable stuff having seen the amount of words wasted about the subject from year 2002. Anyways, if instead of having it as an "alternative" solution inside wine tree (which would make stuffs easier for people needing it, for example cad users) we want to let it hanging on bug 421's page hoping to have the "right" solution in a bit less than another 7 years, ok :-)
Max
Interpreting Alexandre his words Huw his design was the right way to continue (according to Jeremy he had worked on this for 4-5 months) but even for Huw it would take a similar amount of time to finish it. They didn't know well if continuing with the work was worth it for the apps they had to get working and during a discussion at Wineconf they also weren't certain for which apps it would help and more important by how much (e.g. time is also fixing a lot issues as we are getting faster CPUs all the time). With your patches (even if they aren't clean and won't 100% correctly) we see how much a DIB engine (even unoptimized) can already help. Basically a lot of users should test it using different programs. We need benchmark results e.g. photoshop benchmarks and others.
If the DIB engine appears to do wonders for lots of apps (e.g. photoshop, office ...) then some company might sponsor Codeweavers to work on this.
Roderick
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
2009/5/11 Joerg Mayer jmayer@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
On Mon, May 11, 2009 at 6:07 AM, Chris Howe mrmessiah@gmail.com wrote:
2009/5/11 Joerg Mayer jmayer@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.
2009/5/11 Joerg Mayer jmayer@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.
On Mon, May 11, 2009 at 6:20 AM, Henri Verbeet hverbeet@gmail.com wrote:
2009/5/11 Joerg Mayer jmayer@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 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
On Mon, May 11, 2009 at 6:39 AM, Massimo Del Fedele max@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.
Henri Verbeet ha scritto:
2009/5/11 Joerg Mayer jmayer@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
Henri Verbeet wrote:
2009/5/11 Joerg Mayer jmayer@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
2009/5/11 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Joerg Mayer jmayer@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.)
Henri Verbeet wrote:
2009/5/11 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Joerg Mayer jmayer@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
2009/5/12 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Joerg Mayer jmayer@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?
Ben Klein wrote:
2009/5/12 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Joerg Mayer jmayer@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
2009/5/12 Scott Ritchie scott@open-vote.org:
Ben Klein wrote:
2009/5/12 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Scott Ritchie scott@open-vote.org:
Henri Verbeet wrote:
2009/5/11 Joerg Mayer jmayer@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.
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
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:
- 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.
- 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
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:
- 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.
- 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
On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele max@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...
and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae... (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 English ha scritto:
On Sun, May 10, 2009 at 5:19 AM, Massimo Del Fedele max@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...
and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae... (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
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...
and for comparison, here's a vanilla wine test run: http://test.winehq.org/data/60482be24bca109601008df0113b64858dd45863/wine_ae...
(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
-
Austin English -
Ben Klein -
Chris Howe -
Henri Verbeet -
James McKenzie -
Joerg Mayer -
Marcus Meissner -
Massimo Del Fedele -
Ricardo Filipe -
Roderick Colenbrander -
Scott Ritchie -
Warren Dumortier