Having seen many patches related to DIB engine lately, I built latest sources and tried it.... No speed enhancements on AutoCAD, my test app. So, I wonder if the engine is already working, at least partially, or not. If yes, there's some switch/environment variable to enable it ?
Sorry for asking here but, besides of git commits I've seen no explanation about what's happening. Also some users of my old engine, which are blocked to an old wine version (it is no more applicable to git tree since some time, because of recent changes....) would like to know what's going on.
Ciao
Max
On Sun, Jul 24, 2011 at 4:11 PM, Massimo Del Fedele max@veneto.com wrote:
Having seen many patches related to DIB engine lately, I built latest sources and tried it.... No speed enhancements on AutoCAD, my test app. So, I wonder if the engine is already working, at least partially, or not. If yes, there's some switch/environment variable to enable it ?
Hello,
Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better.
Most of the work so far was at an architectural level -- creating the infrastructure to support the incremental development of the DIB engine (see dlls/gdi32/dibdrv/). The new DIB engine is enabled by default, and is activated automatically (pushed onto the driver stack) if you pass a DIB to SelectObject. If the DIB engine doesn't implement some functions, they are forwarded to the next driver on the stack. If some features are not supported (eg. specific pixel formats; pen, or brush styles), it again falls back to the next driver on the stack each time those features need to be used (eg. drawing a line when current pen is not supported).
Current status is: - most pixel formats are supported, if not all (1bpp is a bit special and still has some issues though); - most pens are implemented (except geometric pens, or pens with width greater than 1); - brush support looks pretty much complete; - most graphics primitives are NOT implemented yet.
In fact, the only primitives that are currently implemented are LineTo, Rectangle, PaintRgn, and PatBlt (see [1]), the minimum to test that pens and brushes are working properly; no blits; no polygons, nor other weird shapes; no font rendering; not even get/set pixel. That's probably why Autocad doesn't show any improvements yet. On the other hand, the tricky architectural bits are mostly done, so I'm guessing visible speed improvements are not too far off.
Octavian
[1] http://source.winehq.org/git/wine.git/blob/8c850a82d440786ca4f83e5e061d6b3d3...
Yep, true.... Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now.
Thank you for your answer.... waiting for better times, so :-)
Max
On 7/24/11 10:14 AM, Massimo Del Fedele wrote:
Yep, true.... Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now.
Max:
It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work.
It would give you a good start if Huw decides that your code is better than his!
James
Il 24/07/2011 19:32, James McKenzie ha scritto:
On 7/24/11 10:14 AM, Massimo Del Fedele wrote:
Yep, true.... Autocad would gain benefit just with fonts. If fonts are not implemented, that's useless by now.
Max:
It might be worthwhile to rebase your code on the fixes inputted by Huw so that your patches continue to work until Huw finishes his work.
It would give you a good start if Huw decides that your code is better than his!
James
Hi James,
I guess that would be almost impossible to rebase my code there... For the few I've seen, the approach taken by Huw is too different from mine to have both coexistent, and the infrastructure changes would make the porting quite complicated and, which is worse, too dependent on code base changes to be maintainable by me. The only stuff that could be done would be to submit patches to enhance current graphics primitives.... but I guess Huw has already something in mind, and I've got too few spare time :-) Again, for what (very few indeed) I've understood from patches titles, some low-level primitives were exported from winex11 - gdi32 drivers, a stuff that was told me "impossible" when I developed my engine and that will make easy to solve the biggest problem remaining on it, the mixed DIB-DDB conversions in an efficient way. So, I'll wait to see what happens to Huw engine. A pity because latest progress in wine solved many other problems unrelated to DIB. Autocad users can just hope that fonts primitives will be embedded soon :-)
Ciao
Max
On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote:
Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better.
This is a good summary of where we're at - nicely done Octavian.
The next step is cross-device blitting, which is what Alexandre and I are working on at the moment.
Huw.
Il 25/07/2011 10:20, Huw Davies ha scritto:
On Sun, Jul 24, 2011 at 07:10:46PM +0300, Octavian Voicu wrote:
Disclaimer: these comments are based only on what I gather from following commits and looking at the code, so can't guarantee it's 100% accurate; Huw or Alexandre would know better.
This is a good summary of where we're at - nicely done Octavian.
The next step is cross-device blitting, which is what Alexandre and I are working on at the moment.
Huw.
Indeed that one was the big problem of my engine, impossible to do efficently without support from underlying drivers (winex11).
Is font support for DIBS foreseen in short time ?
Max
-
Huw Davies -
James McKenzie -
Massimo Del Fedele -
Octavian Voicu