What is the purpose of DIB Engine? Is it to speed up DirectDraw apps, or is
it to add missing functionality for DirectDraw „emulation”? I'm asking this
because I recently tested few DDraw apps (Fallout2 and Happyland Adventures)
with DIB enabled and... well for HA there was now significant speed
difference, and Fallout2 slowed down even more . So what's up with DIB
anyway? I thought it was supposed to speed up DDraw apps, but now I'm
confused...
The purpose of the DIB engine is to accelerate as it says DIB drawing ('bitmap drawing'). This operation occurs frequently and right now we let X do this stuff which means we ask X to draw to the bitmap (this might even require a depth conversion operation), then X performs its magic and then we copy the result back from X and give the result back to the program. This can be very slow.
The reason the DIB engine can help a bit for games is because in DirectDraw we use DIBs (unless DirectDrawRenderer is set to opengl). A proper and optimized DIB engine could make our software rendered DirectDraw faster. Though there are lots of other optimizations which can be performed to make it faster. For best performance DirectDrawRenderer should be set to opengl to get hardware acceleration but the optimizations I referred to should also be added for opengl. There is a lot more performance to unlock.
The main use of the DIB engine for DirectDraw (even when combined with opengl) is that some games like Age of Empires use 'win32 gdi' for drawing text to the screen. When they do this we have to convert the game image back to a DIB and then let gdi (and behind the back X render to the bitmap) which is slow..
The purpose of the DIB engine is to accelerate as it says DIB drawing
('bitmap drawing'). This operation occurs frequently and right now we let X
do this stuff which means we ask X to draw to the bitmap (this might even
require a depth conversion operation), then X performs its magic and then we
copy the result back from X and give the result back to the program. This
can be very slow.
The reason the DIB engine can help a bit for games is because in DirectDraw
we use DIBs (unless DirectDrawRenderer is set to opengl). A proper and
optimized DIB engine could make our software rendered DirectDraw faster.
Though there are lots of other optimizations which can be performed to make
it faster. For best performance DirectDrawRenderer should be set to opengl
to get hardware acceleration but the optimizations I referred to should also
be added for opengl. There is a lot more performance to unlock.
The main use of the DIB engine for DirectDraw (even when combined with
opengl) is that some games like Age of Empires use 'win32 gdi' for drawing
text to the screen. When they do this we have to convert the game image back
to a DIB and then let gdi (and behind the back X render to the bitmap) which
is slow..
Roderick
I see, I was wrong then... I always thought DIB's main goal was to speed up
all DirectDraw apps, so they would run with nearly the same speed as when
“good” old DGA was still in use...
Thanks for the answer.
P.S
Do you guys think it is possible to rewrite DirectDraw code somehow, so it
would run with speed comparable to DirectDraw in Windows, without using
opengl?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-us ... chment.htm>
DirectDraw was about direct framebuffer access, so similar to DGA which you just mentioned. The closest to this is opengl. It offers some interesting extensions like pixel buffer objects (PBOs) using which we have something close to direct framebuffer access. There are just things which need to be added to our DirectDraw to make it more efficient.
One of the things which we don't do in Wine but which could bring a lot of speed are 'access traps' (Windows must be using those). Most of the time when a game draws to a surface it only updates a small part but in Wine each time we reupload the whole surface (some games are nice and only 'lock' the part they need but not all). On Windows DirectDraw sets traps on the memory (the actually cause segfaults on purpose) to track which parts got updated. This is a change which could help some games a lot but it is very tricky to implement properly.
. So what's up with DIB
