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
