Slow/erratic 2d paint/redraw events on some games

[Vanessa Dannenberg]

I am finding that with at least one game, Double Solitaire, paint/redraw events are very slow. The same version of wine is on two machines, one with a GeForce 6800, the other with an MX4000. The slowdown is most notable when you resize the window after the initial deal, and the game has to scale the cards and redraw them. An event that used to take less than a second on either machine now takes 2 or so on the faster video card, and upwards of ten seconds on the slower of the two, and is very glitchy and erratic on the latter, slower card.. In this instance, I am using wine version "1.0.0-1-ubuntu4~hardy1" (as reported by adept). Both machines used to run Gentoo, and on that distribution, Wine's performance was fine regardless of which version I was using. No fancy compile/optimize settings were used there (just -O2 and that's it).

If anyone needs the game in question for testing, it can be had freely from here: http://members.aol.com/dbsolitare/

[Francois Gouget (fgouget)]

When a program wants to perform a GDI operation on a DIB, most of the time the
way we proceed is as follows:
 - convert the DIB to a format that X understands
 - invoke the corresponding X operation on the X bitmap
 - convert the X bitmap back to DIB format

This is the case for DrawArc, LineTo and even simple operations such as SetPixel
and GetPixel!
This way of doing things saves us from having to implement quite a few functions
that would each have to handle many bitmap formats. But there are issues too:
 * the copies back and forth can be very costly. Optimizations are possible to
avoid having to do the copies but they don't work in all situations.
 * the X bitmap has to be in the format of the X display. So if X is running in
15bpp, a 32bpp DIB is converted to 15bpp, the operation is performed in 15bpp,
and the bitmap is then converted back to 32bpp. Obviously this implies that each
operation occurs a loss of color resolution (fortunately they should not
accumulate).

Implementing a GDI renderer in Wine would mean that all the above operations
could be done directly on the DIB. This should provide better performance and
also solve the color resolution issues.

Some related emails from the wine-dev archives:
 * 2002/01/28 - Re: A new SDL back-end we've been toying with
   http://www.winehq.com/hypermail/wine-devel/2002/01/0564.html
   starts: http://www.winehq.com/hypermail/wine-devel/2002/01/0519.html
 * 2000/10/27 - microwindows license
   http://www.winehq.com/hypermail/wine-devel/2000/10/0301.html
 * 2000/10/25 - using microwindows/nanogui
   http://www.winehq.com/hypermail/wine-devel/2000/10/0244.html

[Francois Gouget (fgouget)]

I updated the subject to match the most common denomination: DIB engine.

[Johane (johane)]

Sorry, I don't have time to prioritize this task. Daughter calls.

[Oliver-stieber (oliver-stieber)]

how about starting with something like libwmf
http://wvware.sourceforge.net/libwmf.html

As I seem to remember WMF is miore or less just a set of calls to the DIB API,
so libwmf would a tleast be a start.

[Alex-winbabel (alex-winbabel)]

Well, i'm a novice here (in wine and linux), but i think i could help
with this task.

I'm a good windows application developer (www.babel7.com),
and i wrote two programs with some of the semantics you are
looking for:

painting over BMPs (or better DIBs).

The 2 programs are for 256 colors and true RGB.
They write on file BMPs.
The painting functions were written to generate pie graphs,
poligonals, rectangles, and so on, but they can be readapted
to write on DIBs in memory.

The sintax help (comm line wo parms) is in Spanish, but i
will not ask for excuses for it. The use is very simple.
I will rewrite an english sintax help if i begin with the task.

You can download it and test if i could help.
If yes, i will begin with the task...
And time will say!!

http://www.babel7.com/bmps.zip

Regards...

Aljandro Bonet
Babel Informatica SL
Madrid
<email address hidden>

[Mike Hearn (mike-navi)]

Hi Alex, could you post to the wine-devel mailing list with that offer please?

[Jonathan Ernst (jonathan.ernst)]

Any update on this one ?

Thanks.

[Willie-froq (willie-froq)]

Would the DIBEngine be needed to fix #1973? If that's the case, I'll change my
bug report to depend on this one...

[Francois Gouget (fgouget)]

Yes, looks like it is related to me. AFAIK currently we can only perform GDI
operations on DIBs that are in the same format as the X server screen. This is
because all our GDI operations are implemented using calls to the X server and
the X server can only work on bitmaps that are in the same format as the screen.

Note that the latter may not be 100% true with the API extensions in the recent
X server revisions but I don't know the details. IIRC this is one of the ways of
implementing a DIB engine that was discussed but it was ruled out because it
sucks if the X server is remote (because of all the roundtrips).

[Francois Gouget (fgouget)]

Wine still needs a DIB engine and this is blocking quite a few things (e.g.
printing problem for transparent bitmap in PowerPoint, PowerPoint animation
performance issues, but there are many more issues).

TransGaming once posted a patch implementing a very incomplete DIB engine. It
was not merged in Wine due to issues with the approach that was used. I'm not
sure where this patch is now.

More recently ReactOS has been offering code. Steven said:
---
Note: I don't know if its relevant or not but one of the ReactOS developers Ge
van Geldorp has been working on a utility to autogenerate parts of the DIB
Engine that's in ReactOS and has offered to license his work under the LGPL.
According to my discussions with him only certain operations are supported though.
---

A bit of searching in the wine-devel archives would probably turn up a URL to
the relevant code.

[Willie-froq (willie-froq)]

The old Transgaming patch and docs:

http://www.spinics.net/lists/wine/msg05243.html <- patch
http://www.spinics.net/lists/wine/msg05244.html <- docs

Ge van Geldorp's announcement and benchmarks on ros-devel:

http://www.reactos.org/archives/public/ros-dev/2005-July/004063.html

[Willie-froq (willie-froq)]

Excuse my ignorance, but would it make things easier to create a DIB engine
based on EVAS? I mean, EVAS is exceptionally fast, supports hardware
accelleration, the license is compatible with Wine, and it's still network
transparent AFAIK (Enlightenment DR17 should be network transparent?).

BTW, I'd suggest to set the target to 1.0, if that's not too optimistic?

[Futhark77 (futhark77)]

Many people including myself have inquired many times about a noticeable
performance difference with 2D games between Wine and Windows (Starcraft, Dark
Reign and presumably many others). A recent post confirmed 2D drawing in Wine
isn't optimal (sorry for the long link).
http://groups.google.com/group/comp.emulators.ms-windows.wine/tree/browse_frm/thread/461103ade5c4cc8a/36abc41e30cb7b7b?rnum=1&q=dib&_done=%2Fgroup%2Fcomp.emulators.ms-windows.wine%2Fbrowse_frm%2Fthread%2F461103ade5c4cc8a%2F51c8fd23a26845bd%3Fq%3Ddib%26rnum%3D1%26#doc_36abc41e30cb7b7b

I am adding this quick note so that user questions are more directly answered by
this report. It'll also explain better why this issue is listed in a game appdb
entry.

[Damjan Jovanovic (damjan-jov)]

Since this is the place for discussing DIB engine related stuff, I'm posting
here to make you aware of the following.

On bug 3902, a pretty long discussion took place about the slowness of Heroes of
might and magic 4, which was caused by a lot of copying between DIBs and X11
pixmaps.

2 patches were made, one started by Iulian and finished by me, that calculates
the dirty rectangle of a bitmap before copying it, so less data has to be
copied. That patch would have to be extended significantly (every GDI function
has to set/clear the dirty rectangle), but people have reported improved
performance with just BitBlt setting/clearing the rect.

The other patch, which was committed today, was made by me, and it does
client-side copying of 15/16/24/32 bpp bitmaps (if you ever saw the "fixme:
potential optimization - client-side DIB copy", that's where it will help). This
patch vastly improves the performance of Heroes 4.

So can you please test all slow-running apps against the latest Git (or
alternatively against wine 0.9.24 patched with the client-side DIB copy patch
from bug 3902) and report how much it helps?

[Willie-froq (willie-froq)]

Your DIB-copy patch introduced a regression, or exposed a bug. I just tested
Reason 3.0, a pro-audio application by Propellerhead*. The colors of one part
of the interface are completely messed up with your patch applied - hard to
describe. One of the "devices" (MClass Mastering Suite Combi) used to be light
gray, now it's grainy blue/ red/ yellow. The bug seems to be similar to bug
#1973, which is also supposed to be fixable using a real DIB engine.

*) Demo available at: http://www.propellerheads.se

[Damjan Jovanovic (damjan-jov)]

Willie, I'll try the Reason 3 demo tonight and see what's wrong.

Is the speed any better?

[Willie-froq (willie-froq)]

Yep, quite a bit faster. It's actually almost usable now.

But I think I made a mistake, it should be gold/ yellow, not light gray, IIRC.
Anyway, the bug is so obvious, you'll see what I mean.

[Damjan Jovanovic (damjan-jov)]

Although I couldn't open the MClass Mastering Suite Combi (missing file?), I
tested the corrupted play button. I've just submitted a patch for the bug I
think was causing the regression to wine-patches. Bottom-up DIBs were being
misdetected.

Reason 3 makes heavy use of client-side DIB copying. Further work should make
it even faster. Thanks Willie, now I've got a good app to test my work on.

[Alexander Nicolaysen Sørnes (alex-thehandofagony)]

Since the Heroes IV bug was on the 1.0 tasklist because a complete DIB engine
was needed, I'll add this bug instead.

As for good testing applications, the Age of Empires I & II demos might be
useful

http://appdb.winehq.org/appview.php?iAppId=762
http://appdb.winehq.org/appview.php?iAppId=99

[Alexander Nicolaysen Sørnes (alex-thehandofagony)]

*** Bug 6633 has been marked as a duplicate of this bug. ***

[John (auxsvr)]

Maybe bug http://bugs.winehq.org/show_bug.cgi?id=6230 is related to the
Damjan Jovanovic patch? The bug occurs in wine 0.9.12 and 0.9.21-27.

[Damjan Jovanovic (damjan-jov)]

Why don't you do regression test Riven between wine 0.9.20 and 0.9.21?

My patch was applied only in wine 0.9.25, by the way, so something else is at fault.

[The3dfxdude (the3dfxdude)]

*** Bug 4550 has been marked as a duplicate of this bug. ***

[The3dfxdude (the3dfxdude)]

Will everyone interested with this bug report check the code that I have written for a DIB engine. You ought to email me directly for any issues.
http://repo.or.cz/w/wine/dibdrv.git

[Piotr Zaryk (oponek)]

In Reason 3.0 there's an error occuring:
fixme:bitblt:X11DRV_ClientSideDIBCopy potential optimization: pixel format conversion
while resizing the sequencer pool.

[Dan Kegel (dank)]

Alexandre thinks this is probably a post-1.0 issue.

[Piotr Zaryk (oponek)]

Created an attachment (id=8804)
responsible for the slowness?

[Piotr Zaryk (oponek)]

The bug still occurs with wine 0.9.47 on Ubuntu 7.10 Gutsy..

[Stefan Dösinger (stefandoesinger)]

Sorry, I forgot this: I tried CIV4 myself(version from Steam), and I could not reproduce any solid color bugs. Can you attach a screenshot?

[Stefan Dösinger (stefandoesinger)]

Sorry, bugzilla sent me to a wrong bug. This reply was meant for a different bug

[Denis Rut'kov (dendron2000)]

*** Bug 12162 has been marked as a duplicate of this bug. ***

[Jonathan Thomas (echidnaman)]

*** Bug 10744 has been marked as a duplicate of this bug. ***

[Denis Rut'kov (dendron2000)]

I suggest the severity of this bug is changed to major, as it affects a wide range of applications.

[Dmitry-codeweavers (dmitry-codeweavers)]

Please read the Severity descriptions: even Normal as it is now is an over
rate, at most it should be Minor or even Trivial.

[Denis Rut'kov (dendron2000)]

(In reply to comment #33)
In fact, the reason I'm interested in fixing this is Heroes of Might & Magic IV working under wine (not like a slide-show as it is now). But as I investigated more about this bug, I found that it affects many other applications.
Please correct me, if I'm wrong, but this 'bug' represents some core Windows functionality, which realization in wine is far from optimal.

This issue is now 6 years old and is still not fixed. I hoped I see DIB Engine implemented in Wine 1.0, but it seems it won't be there.

It cannot be tagged minor because there is no 'easy workaround present'.

[Dan Kegel (dank)]

Too hard for 1.0. We can probably have it done for 1.2.

[Dmitry-codeweavers (dmitry-codeweavers)]

(In reply to comment #34)

> In fact, the reason I'm interested in fixing this is Heroes of Might & Magic IV
> working under wine (not like a slide-show as it is now).

How have you identified that the slowness in that game is caused by a lack
of DIB engine? Do you have any profiler statistics?

[Scott Ritchie (scottritchie)]

Hmm, since it's confined to 2D games I'm tempted to say this is due to Wine's lack of a DIB Engine, but since you say it was faster on Gentoo we might want to try and rule out some things first. Do you have desktop effects enabled?

Also, I'm sorry I didn't get to this bug report sooner, as the link you provided is now broken :(

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for posting this bug.

Does this occur in newest WINE?

[Vanessa Dannenberg (vanessadannenberg)]

It would appear that this has been resolved, actually.

[Asmageddon (asmageddon)]

Pardon the semi-offtopic talk, but if there already are multiple patches implementing this at least partially, why won't anyone integrate them into Wine...?

[Igor Tarasov (tarasov-igor)]

http://wiki.winehq.org/DIBEngine

[Lain_13 (lain-halfbit)]

(In reply to comment #399)
> You need to run autoconf after applying the patches and before running
> ./configure.

Thanks, it works now.

[Jpmx23 (jpmx23)]

I've been trying to see if Max' DIB engine implementation would have some performance improvements with FL Studio (version 9). However, when I try to launch the program with the "WINEDIB=ON" enviroment variable, I get the "Program error" window ("The program has encountered a serious problem and needs to close") and some errors to the terminal:

fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x3a4
err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x378
fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x3a4
err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x378
fixme:dibdrv:DIBDRV_RealizePalette STUB
fixme:win:LockWindowUpdate (0x200a8), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:dibdrv:DIBDRV_UnrealizePalette STUB
fixme:dibdrv:DIBDRV_PatBlt TEMPORARY - use BitBlt by now
wine: Unhandled page fault on write access to 0x02572000 at address 0x0000:0x68797493 (thread 0009), starting debugger...
fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB

Using wine 1.3.10 with the latest set of patches (1.3.7), compiled just fine. Also have tried with earlier versions, same thing. And although it says "starting debugger", it never starts, the program just hangs after the "Program error" window. Eventually, I have to use 'kill' to stop the process. So, does anyone have any idea what's the thing with this?

[.tomi (dottomi)]

Created an attachment (id=33239)
Wine output (dibdrv trace) for TH06

In Touhou games the text is red instead of white.
Attached a trace log with added output of CalcShiftAndLen values for channels.

[.tomi (dottomi)]

Created an attachment (id=33241)
TH06 colour comparision

Sorry, that should be "almost white". There was a gradient there.

[Lockywolf (lockywolf)]

I have a problem, similar to the autoconf one.

I have ubuntu 10.10 x86_64, wine 1.3.14

I followed the instructions from

http://wiki.winehq.org/WineOn64bit

Ubuntu way

sudo add-apt-repository ppa:ubuntu-wine/ppa
sudo apt-get build-dep wine1.3

then I applied patches (no warnings)

autoconf, configure, make - passed okay.

but when i try to run a program - i receive the annoying

WINEDIB=on /opt/winedib/bin/winecfg

err:driver:Load_Dib_Driver Couldn't load DIB Engine
err:driver:Load_Dib_Driver Couldn't load DIB Engine
err:driver:Load_Dib_Driver Couldn't load DIB Engine
err:driver:Load_Dib_Driver Couldn't load DIB Engine

Any ideas?

[Marko Katić (dromede)]

(In reply to comment #403)
> I've been trying to see if Max' DIB engine implementation would have some
> performance improvements with FL Studio (version 9). However, when I try to
> launch the program with the "WINEDIB=ON" enviroment variable, I get the
> "Program error" window ("The program has encountered a serious problem and
> needs to close") and some errors to the terminal:
>
> fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
> fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
> err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x3a4
> err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x378
> fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
> fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
> err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x3a4
> err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x378
> fixme:dibdrv:DIBDRV_RealizePalette STUB
> fixme:win:LockWindowUpdate (0x200a8), partial stub!
> fixme:win:LockWindowUpdate ((nil)), partial stub!
> fixme:dibdrv:DIBDRV_UnrealizePalette STUB
> fixme:dibdrv:DIBDRV_PatBlt TEMPORARY - use BitBlt by now
> wine: Unhandled page fault on write access to 0x02572000 at address
> 0x0000:0x68797493 (thread 0009), starting debugger...
> fixme:dibdrv:DIBDRV_RealizeDefaultPalette STUB
>
> Using wine 1.3.10 with the latest set of patches (1.3.7), compiled just fine.
> Also have tried with earlier versions, same thing. And although it says
> "starting debugger", it never starts, the program just hangs after the "Program
> error" window. Eventually, I have to use 'kill' to stop the process. So, does
> anyone have any idea what's the thing with this?

I tried the same thing. I'm running ubuntu 10.10 64bit. i compiled my patched wine 1.3.7 in a 32bit ubuntu vmware box and then copied it to host. It runs fine and the DIB engine seems to be working. I tried running regedit or winecfg with WINEDIB=ON and i get typical "err:dibdrv:" errors which i presume means that the DIB engine is working. Fl studio 9 demo works just fine with WINEDIB=ON but i see no changes in performance, the gui still slows to a crawl if i open the piano roll.
Strangely, i don't get any DIB related errors while running FL studio.
Here's my output:

fixme:dwmapi:DwmIsCompositionEnabled 0x33f974
fixme:win:LockWindowUpdate (0x200bc), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:bitblt:client_side_dib_copy potential optimization: pixel format conversion
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",0x251ea08): stub
fixme:avrt:AvSetMmThreadPriority (0x12345678)->(2) stub
fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x18eae8,0x18e9b8): stub
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",0x271e9ec): stub
fixme:avrt:AvSetMmThreadPriority (0x12345678)->(2) stub
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",0x2b3ea08): stub
fixme:avrt:AvSetMmThreadPriority (0x12345678)->(2) stub
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",0x251ea08): stub
fixme:avrt:AvSetMmThreadPriority (0x12345678)->(2) stub
fixme:shell:PathUnExpandEnvStringsA ("C:\\Program Files\\Image-Line\\FL Studio 9.8 beta\\Artwork\\Skins\\Default\\StartSnd.WAV","",0x00000105)
fixme:s...

[.tomi (dottomi)]

(In reply to comment #406)
> I have a problem, similar to the autoconf one.
>
> I have ubuntu 10.10 x86_64, wine 1.3.14
>
> I followed the instructions from
>
> http://wiki.winehq.org/WineOn64bit
>
> Ubuntu way
>
> sudo add-apt-repository ppa:ubuntu-wine/ppa
> sudo apt-get build-dep wine1.3
>
> then I applied patches (no warnings)
>
> autoconf, configure, make - passed okay.
>
> but when i try to run a program - i receive the annoying
>
> WINEDIB=on /opt/winedib/bin/winecfg
>
> err:driver:Load_Dib_Driver Couldn't load DIB Engine
> err:driver:Load_Dib_Driver Couldn't load DIB Engine
> err:driver:Load_Dib_Driver Couldn't load DIB Engine
> err:driver:Load_Dib_Driver Couldn't load DIB Engine
>
> Any ideas?

AFAIK one of the current patches should have failed. At least the patch that addes a directive to configure.ac for adding the winedib.drv directory to the list of directories inside which to create a Makefile did for me.
See if dlls/winedib.drv contains a Makefile. If not then add
WINE_CONFIG_DLL(winedib.drv)
around line 2812 in configure.ac and rerun autoconf and make.

[Minqiang (ptpt52)]

Created an attachment (id=33562)
DIB Engine - Rebased on wine-1.3.15

DIB Engine - Rebased on wine-1.3.15

The engine rebased due to some changes in configure.ac.

-ptpt52

[Minqiang (ptpt52)]

Hi, Max
why the the dibengine patch can't be accepted by the wine reps?

[Minqiang (ptpt52)]

i run many games on wine, such as:
Counter-Strike 1.6(on Steam)
Age of Empires III
Soldat
Commandos3
War3(Warcraft III, Frozen Throne)
DeusEx(DeusEx: Goty)

after a great tests with Max's DIB Engine patch, I find several bugs:

--The fonts in game display really bad on many games

--The mouse disappear in some case(when i select a settler and point the mouse to other objects like tree, TC, animal) on running AOE3 game

--The output on terminal shows this many times:
err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x3a4
err:dibdrv:_BITMAPLIST_Terminate Unfreed DIB found, handle is 0x378

I think somebody should rewrite the dib engine, i mean a totally rewrite, because the dib engine code is base on the old wine source, but the current wine source is really up to date with many bugs fixed

as i can see, the games above run well on the original wine without DIB Engine except for slowness in some case.

anyway, the DIB Engine really increase the the performance on some games. thx Max.

[Minqiang (ptpt52)]

Hi, Max
I have an idea, we can write the dib operations in to the "winex11.drv" module instead of writing a new "winedib.drv" module.

and we can set a switch that the winex11.drv module choose to use the default operations or the dib operations. I think this should be accepted by the wine repos.

[Chucky (lechuck)]

Hi Chen,

Not criticisms, just questions to be sure we don't miss the target :

 - what about the MacOS X guys who do not have X11 installed ?
 - what performances will it provide under Wayland (nearly compatible X11 replacement in future distros)

By the way, I am using neither of those yet.

Michel Nolard

[MicioMax (max-veneto)]

Hi all :-)

About Chen Minqiang comments :

1) the DIB engine won't be accepted, in particular if embedded in winex11.drv.
This has already been discussed thousands of times.

2) Embedding it in winex11.drv would mean to rebase it on EVERY wine change; summed with point 1 would mean an huge work for the maintainer, and I don't have time anymore for it.

3) About the bugs : last time I tested it, winedib.drv passed MORE tests than original winex11 alone.
That said, the code is fully and extensively commented (even too much, on some people's opinion...), so if you want to fix some bugs, you're wellcome.
As I said some time ago, I don't have much time anymore to fix them and, as it would be never included in official wine, it's almost an useless task.

4) winedib code is NOT based on old source code; it's a "bridge" between gdi and winex11 and, besides some very late changes, is up to date with wine codebase; by design it will be so for long time, besides the need to rebase configure.ac file from time to time.
That said, if somebody wants to take the task of rewriting it from scratch he's *very* wellcome :-)

Ciao

Max

[Diafero (diafero)]

Since one of the recent wine updates (1.3.15 or 1.3.14, not sure), the game I needed the DIB engine for is now working fine without this patch - which I actually only noticed as the patch stopped working for me on current wine (apps would no longer start with WINEDIB=ON).

[MicioMax (max-veneto)]

(In reply to comment #415)
> Since one of the recent wine updates (1.3.15 or 1.3.14, not sure), the game I
> needed the DIB engine for is now working fine without this patch - which I
> actually only noticed as the patch stopped working for me on current wine (apps
> would no longer start with WINEDIB=ON).

Still not checked, but from what I see in changelogs, latest changes completely screw up the DIB engine mechanics.... so I guess it'll need a big refactoring.
OR, hopefully, latest changes are done to make possible the introduction of correct DIB handling in wine ?

Ciao

Max

[Jjmckenzie51 (jjmckenzie51)]

Max:
Looks like Huw is picking this up again. http://source.winehq.org/patches/data/72850 is "gdi32: Add a skeleton dib driver." This has NOT been approved, yet. I'm going to look at the rebased patch to see if it applies cleanly to 1.3.17 and if it will compile.

[Erich E. Hoover (ehoover)]

(In reply to comment #417)
> Max:
> Looks like Huw is picking this up again.
> http://source.winehq.org/patches/data/72850 is "gdi32: Add a skeleton dib
> driver." This has NOT been approved, yet. I'm going to look at the rebased
> patch to see if it applies cleanly to 1.3.17 and if it will compile.

Either that patch was an April Fool's joke or Huw forgot to check something in:
----
...
dc.o: In function `alloc_dc_ptr':
/home/ehoover/src/wine-git/dlls/gdi32/dc.c:82: undefined reference to `dib_driver'
/usr/bin/ld: dc.o: relocation R_386_GOTOFF against undefined hidden symbol `dib_driver' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
----

[r6144 (rainy6144)]

Created an attachment (id=34870)
Additional patch needed for 1.3.20

I tried to apply the patch in comment #409 to wine-1.3.20, but then setting WINEDIB=ON instantly crashes all applications.

The attached patch seems to solve the problem.

[pYrO1v1aniac (pyro-1v1aniac)]

Won't patch to source for Wine 1.3.21

Fails at

dib-engine-0003-fork-ddb-dib-behavi.patch

With loads of errors.
I'm not fantastic at this, and I'd really appreciate it if somebody that could get this compiled could upload a deb or update the instructions for how to patch and compile it.

Though only if it's not a bother, I'm not demanding anything. Winedib enabled in registry no longer works.

[Jeff Cook (jeff-h)]

(In reply to comment #420)
> Won't patch to source for Wine 1.3.21

Please see http://www.winehq.org/pipermail/wine-patches/2011-April/100557.html . An engine written by Huw Davies has been under development in the main WINE tree since April. I don't know if Max's engine is still necessary; you may want to test with the latest WINE and roll back to the last known good version of this patch, since I don't know if the conflicting engines would cause problems or not.

I was quite surprised to see so little information divulged about such a major step for WINE. As we know from this bug, a DIB engine has been one of the most requested and longest-standing bugs in WINE, so for it to be merged essentially without commentary is a bit funny. I'd like to get perspectives from Max and others on the subject and on the engine that's being merged now if they have a minute.

[Jjmckenzie51 (jjmckenzie51)]

(In reply to comment #421)
> (In reply to comment #420)
> > Won't patch to source for Wine 1.3.21
>
> Please see http://www.winehq.org/pipermail/wine-patches/2011-April/100557.html
> . An engine written by Huw Davies has been under development in the main WINE
> tree since April.
Huw has been quite busy and Max's patch, as noble as it is, should no longer apply nor be used. There may be portions that may work, still, but that is much work. I applaud Huw for staying with this effort and his continuous 'grinding' at building a functional DIB engine. I also applaud Max for staying with this as well.

[Frédéric Delanoy (frederic-delanoy)]

(In reply to comment #421)
> I was quite surprised to see so little information divulged about such a major
> step for WINE. As we know from this bug, a DIB engine has been one of the most
> requested and longest-standing bugs in WINE, so for it to be merged essentially
> without commentary is a bit funny.

It's still far from complete ATM, and may not be for some time.
And Wine Weekly News have not been updated since Feb 2009. Volunteers are welcome!

[Ken Sharp (kennybobs)]

*** Bug 26932 has been marked as a duplicate of this bug. ***

[Prometh (prometh)]

Hurry the f*ck up.

[Dan Kegel (dank)]

Huw's working on it pretty hard, I think.

If it were easy, it would have been done long ago.

[MicioMax (max-veneto)]

(In reply to comment #421)
> (In reply to comment #420)
> > Won't patch to source for Wine 1.3.21
>
> Please see http://www.winehq.org/pipermail/wine-patches/2011-April/100557.html
> . An engine written by Huw Davies has been under development in the main WINE
> tree since April. I don't know if Max's engine is still necessary; you may want
> to test with the latest WINE and roll back to the last known good version of
> this patch, since I don't know if the conflicting engines would cause problems
> or not.
>
> I was quite surprised to see so little information divulged about such a major
> step for WINE. As we know from this bug, a DIB engine has been one of the most
> requested and longest-standing bugs in WINE, so for it to be merged essentially
> without commentary is a bit funny. I'd like to get perspectives from Max and
> others on the subject and on the engine that's being merged now if they have a
> minute.

Surprised too about lack of information, but anyways.... who cares ?
Soon or late it'll be completed, I hope soon, of course.
I've *not* looked at current Huw's implementation.... I lost interest in DIB engine long time ago. It's just a pity that my patchset got broken, so who needs the "old" dib engine should stay with an older wine version too.

I just tested the actual implementation, but, for my purposes, it doesn't speed up anything. Your mileage may vary, of course.
AFAIK, most of apps needing it needs font drawing speedup, and there's still no trace of dib font drawing in new engine, and that one isn't a trivial task.
My engine implemented it with some glitches, but at least it was usable.
Also, I've got no idea if Huw is grabbing something of my code or not, but I guess not.

BTW, as a user, I would have liked something a bit more useful, or at least something which wouldn't break completely the "old almost working engine", as many people used it, but of course it's not under my control.
Nor I've time to rebase the old one on current three, mostly because, as far as I can see, the interface is still changing too much and it'll be a very time consuming task.

So, cross your fingers (as usual) and hope :-)

Ciao

Max

[Jjmckenzie51 (jjmckenzie51)]

(In reply to comment #425)
> Hurry the f*ck up.

Huw has been working on this for several YEARS and finally has a .plan to implement most, if not all, of the DIB functionality. This WILL TAKE TIME. This 'bug' is almost ten years old and many people, Max included, have picked up and had to put this down because of the complexity of DIB engine implementation. And your comment certainly will NOT speed things up. Each addition has to be thoroughly tested to insure that nothing existing is broken.
There is a phrase that goes back in this project, this project, like it's real world liquid beverage gets better over time. Some things have to 'brew' for years before they are consumable. Patience is the best thing for both. In other words, no code will be added before it's time and it has appropriately 'fermented' and is implemented properly and with much forethought.

[Prometh (prometh)]

(In reply to comment #428)
> this project, like it's real world liquid beverage gets better over time.

I drink beer. Heh, but in all seriousness, I am a fully grown impatient child who wants to play games from his increasingly distant childhood. Are you saying that it's OK to deprive me of that satisfaction? GIVE ME WHAT I WANT!!!

[Dan Kegel (dank)]

We don't need that kind of grief here. I've disabled Steven Vachon's bugzilla account for now.

[pYrO1v1aniac (pyro-1v1aniac)]

Wow... What an ass.

I just wanna say, I've been through the ups and downs with this one over the years, and I'm extremely grateful (and always have been) for the hard work and dedication of the devs on projects like this.

With what little I know of this sort of coding, I know it's horrible, usually thankless work. It's a shame Max's dib engine never made it into the main wine tree, whether it was for political or implementation reasons, but I want to thank him for the 2 or so years I was able to play Age of Empires II: The Conqueors on my linux box before the main wine tree would no longer compile with his engine. You made my computing experience a bit better and I gave you nothing for it.

I'm also excited about the work Huw is putting in, but I can be patient in the knowledge that some day it'll work, like so much stuff from Linux has in the past. I feel it's worth noting here that on the latest version of Windows, many of the games and applications affected by this bug no longer function, and it's from this we can see one of the great things about this community; As microsoft leaves a wake of broken software behind with each new version, projects like Wine continue to improve compatibility, even with old software from another platform.

I'm keeping the faith in you guys, and I want you to know not everyone is a detractor.

[At-andrew-n1 (at-andrew-n1)]

Can people please remember this is a bug tracker NOT a discussion forum.

I'd like to use this bug as intended, to track the the implementation of a DIB engine. At the moment I believe that is being done in Huw's project, so can you please take all discussion unrelated to this off to the mailing list.

[pYrO1v1aniac (pyro-1v1aniac)]

As of Wine 1.3.28, Age of Empires 2: The Conquerors now has 'acid trippy' graphical glitches. This coincides with various DIB related changes.

Possible regression in this bug.

[Lain_13 (lain-halfbit)]

(In reply to comment #433)
> As of Wine 1.3.28, Age of Empires 2: The Conquerors now has 'acid trippy'
> graphical glitches. This coincides with various DIB related changes.
>
> Possible regression in this bug.

Unfortunately no. This DIB engine never was accepted into wine. They started to implement own DIB engine instead of this one few dev-releases ago. So, you have to open separate bug about your problem (or search for existing one).

[Julian Rüger (jr98)]

I can confirm the "acid trip" colors in the menu in Age of Empires 2 and The
Conquerors. When trying to start playing the game freezes and I get a lot of
fixmes like this:

err:d3d_surface:d3dfmt_p8_init_palette This code should never get entered for
DirectDraw!, expect problems

Let me know if you need more details.

@Lain 13: Correct me if I'm wrong, but this bug is not about Max's DIB-engine in particular, but DIB-engine in general. It may be better to open a new bug for the mentioned problems anyway, this place is crowded enough.

Maybe it is even time to close this bug for good, since we DO have a DIB-engine in the main tree now (complete or not) and remaining problems and regressions should be reported in seperate bugs. Opinions?

Best regards,
Julian

[Dan Kegel (dank)]

Yeah, the basic dib engine is there now. Any problems
or inadequacies in it deserve new bugs.

[Alexandre Julliard (julliard)]

Closing bugs fixed in 1.3.29.

[Austin English (austinenglish)]

Removing deprecated 'All' Platform/OS.

[Jaime Rave (jaimerave)]

This bug is fixed in Wine 1.4 that is in the current repositories.