Hi,
I've recently tried to play Heroes of Might and Magic IV under Wine, which has very poor performance and this message it printed out many, many times after the game is started:
fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy
After doing some digging it appears the problem is the current DIB engine or lack thereof (the DIBEngine page on the Wine wiki and the bugzilla bug it links to are very useful). From what I can tell this has been a known shortcoming in Wine for at least 4.5 - 5 years, with a few partial patches created three or four years ago. Is (or has) there any recent (less than a year old) work being done on creating a more efficient DIB engine for Wine? If not, has anyone looked into using a library like EVAS or Cairo as a foundation for implementing it?
Before anyone asks, yes I'm a newbie in terms of hacking on Wine or working with device independent bitmaps under Windows, and yes I am volunteering to help work on an improved DIB engine. :)
Thanks, Brian
P.S. I've run other games such as Diablo II and Total Annihilation (including more recently being able to use TA: Mutation) under Wine and they work beautifully. Keep up the good work!
Jen: Wings? I don't have wings! Kira: Of course not. You're a boy.
- from "The Dark Crystal"
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
satyr_22901@yahoo.com wrote:
After doing some digging it appears the problem is the current DIB engine or lack thereof (the DIBEngine page on the Wine wiki and the bugzilla bug it links to are very useful). From what I can tell this has been a known shortcoming in Wine for at least 4.5 - 5 years, with a few partial patches created three or four years ago. Is (or has) there any recent (less than a year old) work being done on creating a more efficient DIB engine for Wine? If not, has anyone looked into using a library like EVAS or Cairo as a foundation for implementing it?
Have a look at:
http://wiki.winehq.org/DIBEngine
The reason it hasn't been done is because it's hard. I'd recommend you have a go at fixing some other smaller bugs and getting used to Wine development before committing any time to working on a DIB engine.
Mike
On Thursday 24 August 2006 21:30, Mike McCormack wrote:
The reason it hasn't been done is because it's hard.
It's not all that hard since the algorithms involved are all well-documented. It's just a lot of work. The hard part isn't the coding, it's getting Alexandre to accept it, and considering the amount of work involved you *really* want to be certain it's going to be accepted before doing it.
Hi,
I've recently tried to play Heroes of Might and Magic IV under Wine, which has very poor performance and this message it printed out many, many times after the game is started:
fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy
After doing some digging it appears the problem is the current DIB engine or lack thereof (the DIBEngine page on the Wine wiki and the bugzilla bug it links to are very useful). From what I can tell this has been a known shortcoming in Wine for at least 4.5 - 5 years, with a few partial patches created three or four years ago. Is (or has) there any recent (less than a year old) work being done on creating a more efficient DIB engine for Wine? If not, has anyone looked into using a library like EVAS or Cairo as a foundation for implementing it?
Before anyone asks, yes I'm a newbie in terms of hacking on Wine or working with device independent bitmaps under Windows, and yes I am volunteering to help work on an improved DIB engine. :)
Thanks, Brian
When you look in the mailinglist archives you will find lots of topics regarding a DIB engine. A usefull post is this one written by Transgaming: http://www.winehq.com/hypermail/wine-patches/2002/09/0251.html.
So lets say you are using powerpoint and it uses 16bit DIBs for drawing while your Xserver runs at 24bit. This works fine on windows but X has limitations like that allows you to render only at the same depth as the Xserver is using. Further DIBs allows programs to directly draw into its memory and also allow you to use GDI functionality. Wine does a lot of magic to allow this functionality and it also takes into account depth conversion. The syncing between the 'X image' and the 'application' image is not that efficient because it requires Xserver calls and it is even worse when depth conversion is needed.
In case of games there are two reasons why DIB-stuff is used. In plain directdraw we use DIBs for color conversion e.g. when the game uses 16bit and X uses 24bit they are used only for this version. The other case is when a game uses GetDC to mix ddraw rendering with GDI rendering. This is for instance what Age of Empires2 uses and to make it worse it uses 8bit palleted mode aswell.
In theory a DIB engine would help both types of games. The first class of games (if they don't use GetDC and friends) was accelerated in the past using DGA and those games were very fast. These days we also have a directdraw->opengl renderer in Wine (set Direct3D\DirectDrawRenderer to opengl instead of the default gdi). Then opengl does the color conversion for us, it isn't limited by X depth limitations. Our opengl renderer doesn't work for all types of games yet in some games multithreading issues appear which we don't handle correct yet. In some cases when the format isn't supported by opengl we still need to do depth conversion in software.
I would check what type of rendering your game uses as perhaps fixing the ddraw->opengl renderer can be enough already if the game uses a sane color depth format like 16bit.
If the game really needs a DIB engine a good discussion here is needed on how to proceed. Writing the DIB engine itself (all the drawing code) is not that hard the most difficult thing is how to properly integrate this all with gdi and wine's x11drv. I don't think wine wants to depend on other libraries like cairo and second integrating those with wine could be tricky aswell. Further Wine might need a gdiplus.dll in the future which offers similar functionality as cairo and friends.
Regards, Roderick
When you look in the mailinglist archives you will find lots of topics regarding a DIB engine. A usefull post is this one written by Transgaming: http://www.winehq.com/hypermail/wine-patches/2002/09/0251.html.
I've read several of the posts about a DIB engine, including that one (which is linked from bug #421).
So lets say you are using powerpoint and it uses 16bit DIBs for drawing while your Xserver runs at 24bit. This works fine on windows but X has limitations like that allows you to render only at the same depth as the Xserver is using. Further DIBs allows programs to directly draw into its memory and also allow you to use GDI functionality. Wine does a lot of magic to allow this functionality and it also takes into account depth conversion. The syncing between the 'X image' and the 'application' image is not that efficient because it requires Xserver calls and it is even worse when depth conversion is needed.
In case of games there are two reasons why DIB-stuff is used. In plain directdraw we use DIBs for color conversion e.g. when the game uses 16bit and X uses 24bit they are used only for this version. The other case is when a game uses GetDC to mix ddraw rendering with GDI rendering. This is for instance what Age of Empires2 uses and to make it worse it uses 8bit palleted mode aswell.
In theory a DIB engine would help both types of games. The first class of games (if they don't use GetDC and friends) was accelerated in the past using DGA and those games were very fast. These days we also have a directdraw->opengl renderer in Wine (set Direct3D\DirectDrawRenderer to opengl instead of the default gdi). Then opengl does the color conversion for us, it isn't limited by X depth limitations. Our opengl renderer doesn't work for all types of games yet in some games multithreading issues appear which we don't handle correct yet. In some cases when the format isn't supported by opengl we still need to do depth conversion in software.
I would check what type of rendering your game uses as perhaps fixing the ddraw->opengl renderer can be enough already if the game uses a sane color depth format like 16bit.
Ah, that is definitely good to know. I shall have to figure out which type the game is using (looking at a trace of bitmap and bitblt calls, it appears to be copying numerous blocks from different sources all to the same destination but only like every 4th to 10th call triggers the fixme message about client-side DIB copying). Hopefully the game falls in that first class and a little work on the ddraw->opengl renderer will bring the game performance up to a decent level.
If the game really needs a DIB engine a good discussion here is needed on how to proceed. Writing the DIB engine itself (all the drawing code) is not that hard the most difficult thing is how to properly integrate this all with gdi and wine's x11drv. I don't think wine wants to depend on other libraries like cairo and second integrating those with wine could be tricky aswell. Further Wine might need a gdiplus.dll in the future which offers similar functionality as cairo and friends.
Quite understandable, especially concerning avoiding additional library dependencies. For now I shall bow out of that DIB engine discussion (assuming someone else were to start it--I know I'm not currently qualified to do so), and hope that HOMM4 performance can be improved without writing the DIB engine. ;)
Thanks for the detailed info, Brian
-------- Jen: Wings? I don't have wings! Kira: Of course not. You're a boy.
- from "The Dark Crystal"
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
If the game really needs a DIB engine a good discussion here is needed on how to proceed. Writing the DIB engine itself (all the drawing code) is not that hard the most difficult thing is how to properly integrate this all with gdi and wine's x11drv. I don't think wine wants to depend on other libraries like cairo and second integrating those with wine could be tricky aswell. Further Wine might need a gdiplus.dll in the future which offers similar functionality as cairo and friends.
My slightly crazy plan to fix the gaming issues is to write a gdi driver which uses opengl for rendering. To avoid implementing all nasty gdi stuff I hope I can keep a classic hdc and fall back to this(including downloading the surface from opengl, ...). I plan to implement the most common gdi calls, like drawing text.
The problem with just having a gdi engine is that if d3d games call getDC on the render target we would still have to download and upload the whole render target. A game that needs this is Empire Earth, and the D3D7 sdk d3d demos are good testing apps. With implementing the most important gdi calls in gl and a gl renderer for ddraw we can avoid the need for a gdi endine for DDraw and D3D games.
On Thu, Aug 24, 2006 at 03:57:43AM -0700, satyr_22901@yahoo.com wrote:
I've recently tried to play Heroes of Might and Magic IV under Wine, which has very poor performance and this message it printed out many, many times after the game is started:
fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy
assuming that this is the real problem for the poor performance you might squeeze quite some speed out if you get rid of the FIXMEs by redirecting the output to /dev/null. if there are really _lots_ of errors like this it takes quite some time to render them depending on your terminal.
at least this reminds me, that i wanted to test homm3 with wine as the native version no longer works with current linux/glibc/64-bit/godknowswhy.
--- Christoph Frick frick@sc-networks.de wrote:
On Thu, Aug 24, 2006 at 03:57:43AM -0700, satyr_22901@yahoo.com wrote:
I've recently tried to play Heroes of Might and Magic IV under
Wine,
which has very poor performance and this message it printed out
many,
many times after the game is started:
fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy
assuming that this is the real problem for the poor performance you might squeeze quite some speed out if you get rid of the FIXMEs by redirecting the output to /dev/null. if there are really _lots_ of errors like this it takes quite some time to render them depending on your terminal.
Redirecting output to /dev/null doesn't buy any (noticeable) speed. I mentioned the message being repeated rather often as I suspect that the optimization the fixme is suggesting may be what is needed to speed up homm4, not that the printing of the message itself is slowing down the game. ;)
at least this reminds me, that i wanted to test homm3 with wine as the native version no longer works with current linux/glibc/64-bit/godknowswhy.
Not surprising it is broken; I have the Linux version of Heavy Gear 2, and it won't run without pulling old versions of the libraries it needs (like freetype1) from a 32-bit system.... and even then--and also a couple of years ago running it on a newer 32-bit system--using the r300 DRI driver led to corrupted text... but that's getting way off topic and has nothing to do with using Wine or even running closed-source native Linux games... lol
- Brian
-------- Jen: Wings? I don't have wings! Kira: Of course not. You're a boy.
- from "The Dark Crystal"
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Am Donnerstag, 24. August 2006 14:04 schrieb Christoph Frick:
On Thu, Aug 24, 2006 at 03:57:43AM -0700, satyr_22901@yahoo.com wrote:
I've recently tried to play Heroes of Might and Magic IV under Wine, which has very poor performance and this message it printed out many, many times after the game is started:
fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy
assuming that this is the real problem for the poor performance you might squeeze quite some speed out if you get rid of the FIXMEs by redirecting the output to /dev/null. if there are really _lots_ of errors like this it takes quite some time to render them depending on your terminal.
The very same problem plagues not only games, but also a few pro audio apps. And redirecting the output doesn't help at all. Most noticable with Reason, which is unbelievable slow due to interface redraws. With the main window minimized, it works like a charm (but is unusable for obvious reasons, being an audio production app and all that).
Ciao, Willie
On Thursday 24 August 2006 14:04, Christoph Frick wrote:
at least this reminds me, that i wanted to test homm3 with wine as the native version no longer works with current linux/glibc/64-bit/godknowswhy.
http://appdb.winehq.org/appview.php?iVersionId=574 :)
It's missing DirectPlay for multiplayer, and the sound's a bit jiggery. Apart from that, it works like a charm.
Cheers, Kai
Fredag 25 august 2006 14:51, skrev Kai Blin:
On Thursday 24 August 2006 14:04, Christoph Frick wrote:
at least this reminds me, that i wanted to test homm3 with wine as the native version no longer works with current linux/glibc/64-bit/godknowswhy.
http://appdb.winehq.org/appview.php?iVersionId=574 :)
It's missing DirectPlay for multiplayer, and the sound's a bit jiggery. Apart from that, it works like a charm.
DirectPlay should work as well, following the instructions at http://wiki.winehq.org/DirectPlayGames#preview However, it will crash when exiting, because of bug #5534
Regards,
Alexander N. Sørnes
Cheers, Kai
-
Alexander Nicolaysen Sørnes -
Christoph Frick -
Kai Blin -
Mike McCormack -
Roderick Colenbrander -
satyr_22901＠yahoo.com -
Stefan Dösinger -
Troy Rollo -
Willie Sippel