Hello again. Today I got following question: 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... Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.winehq.org/pipermail/wine-users/attachments/20090607/1072c6b7/attachment.htm>
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
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.