World Wine News

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

I started fixing failures against test suite. Most of bitmap ones are fixed, remaining are due to still stubbed funcs.

Now the problem is that it fixed also most todo_wines on bitmap suite....

As usual, on bug 421 page for who wants to test it.

Ciao

Remaining bugs are related to : 1) Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right.Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-)
2) an AlphaBlend() call which should fail and doesn't. Here I really don't know why it should fail..... Uninfluent, anyways.
3) GetDIBits on a source DIB with BPP less then 8 fails to retrieve the original DIB palette, and synthesizes a new one instead. For the moment I found no simple way to grab the palette from inside GetDIBits without maintaining a linked list of HBITMAP to internal bitmaps. Not worth the effort for the moment anyways. If somebody notices weird colors due to it, I'll try to fix.....
There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-)
Austin, could you please retest it against test suite ?
(code on Bug421 page)
Ciao
Max

I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite.... also all bitmap's todo_wines, so expect some "false positive" signaled by tests.

Austin, could you please re-run it on your test machines ?
Ciao
Max

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.

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.

Hello (mostly wine package maintainers),
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

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.

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

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

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,

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?

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

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.

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

1) 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.

2) 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.

Well, I guess I expressed myself not completely corrected. [For 1) ] 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.

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.

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.

[For 2] I agree with you that the DDB caching of DIBs should be a winex11 stuff and totally transparent to gdi32.

Thanx for answers

Max

A: An HLSL compiler for one, although this language is very similar to GLSL. Microsoft moved the shader compiler out of d3d10 core, so we don't need a compiler for d3d10. However, we've a gsoc project going on to look at a HLSL compiler.

A: We reused the existing wined3d code. There were some changes needed to add support for parsing SM 4.0 bytecode, merging buffers. More things are needed. Henri did a lot of work on this, he can give you more details.

A: No, but dx11 will be out in a few months, and sooner or later there will be dx10 apps. We shouldn't fall too back behind.

A: It's mostly corner cases, and dealing with driver limitations. That can be a quite nasty thing though. e.g. take the texldd instruction. On ATI cards there's a GLSL extension for this. But on Nvidia cards, a similar feature only exists in GL_NV_fragment_program. So to properly handle this we have to prop up our ARB shader backend to shader model 3.0 using the NV specifc extensions. A lot of work for a tiny instruction. Other things are making sure that we work properly with more than just the nvidia driver. For example, I am tracking the memory manager based rewrite of the radeon mesa driver to test and file bugs, etc. The aim is that someday we can claim that "dx9 apps work", and not "dx9 apps work when you use card X driver Y on operating system Z".

I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput.

It's got a fair few problems, I'm mainly interested in feedback on the approach, although obviously any code or style criticisms are welcome.

Current limitations:
* Doesn't check for XInput2.h, so it won't build without it. (Laziness) It will _run_ without XInput2, falling back to the current dinput WndProc hooks even if compiled with XInput2 support.

* Doesn't send button-ups; XI2 can't distinguish button up from down

* Doesn't send events after button-down until after button-up on a window. I'm pretty sure this is an XI2 bug, but it might be a design feature.

* Doesn't support exclusive mode. XI2 bug (grabs not yet implemented) Hopefully this can be implemented entirely within the dinput code in winex11drv (ie disabling and hiding the mouse on acquire. dinput already takes care of unacquiring when we are no longer the foreground app)

* Mouse buttons aren't remapped nicely downwards. Need to look harder at this, my mouse reports buttons 1, 2, 3, 4, 5, 8, 9, 10, 11 and 12 under X. 4 and 5 are scroll, 6 and 7 might be horizontal scroll in which case if this is always the case we can just remap downwards. Might need to implement device querying to confirm mouse button mapping...

* Only supports the Mouse. Adding keyboard support should be really trivial compared to actually getting the framework right.

* Doesn't detect capabilities... A mouse with a horizontal scroll wheel'd have four axes. I haven't looked to see if DirectInput can support that, or if our dinput code can easily accomodate more axes or buttons than the current 3/8 setup. This the point we'd need another callthrough from gdimouse to the graphics driver.

* Assumes a process will only try and acquire the mouse once. I'm not sure that this is a bad assumption, and it might be that dinput makes this a valid assumption for us.

* Assumes no one else wants GenericEvents. Some day we'll need a GenericEvent handler system inside WineX11, particularly if wintab gets converted to XInput 2 support. Easy enough to do now if wanted.

* gdimouse uses Wine Mouse GUID value. I'm not sure where these come from, if anywhere. Trivial to fix before submission.

If this format is fine, then the first patch is basically ready to go, the latter two patches may need to be re-split or merged more sensibly.

In the libs folder I've also attached a couple of fixes for the XI2 stuff if anyone wants to try it. One only affects 64-bit builds, and one fixes XCB locking assertions which you could probably otherwise ignore. So they're both kinda optional in the Wine context.

Also one more patch, against the xinput utility from whot's git tree, to fix a compile failure in the XI2 test functionality.