DIB Engine & GSoC
stefandoesinger at gmx.at
Thu Mar 1 15:07:00 CST 2007
Am Donnerstag 01 März 2007 14:03 schrieb Benoit Pradelle:
> I would like participate to the Google Summer Of Code with Wine by
> implementing a DIB Engine. I've searched a lot of informations about the
> DIB Engine but i still got one question :
> for you, how important is a DIB Engine in Wine ?
Hard to say, it depends on what applications are needed.
If I said now "the most important thing" that would be obviously wrong,
otherwise someone would have implemented it already. I'd say it is one of the
top ranked items, but it requires a lot of work and a LOT of knowledge by the
programmer. From the importance vs work required it is rather low.
The DIB engine would help applications which operate on DIB sections with both
direct access and GDI commands. For example DirectX games which use
IDirect*Surface?::GetDC regularly, or other applications(I think MS
powerpoint is one of them). It will not help Direct3D applications which do
not use GetDC.
It would also allow is a X-Server / <Apple something> independent GDI
implementation. Right now our GDI implementation can only do what the X
server can do - not more.
Another question is if the existing implementation using the X server can't be
optimized. One inefficient thing is that always the full DIB section is
converted and copied over. That is technically not necessary when a small
letter is drawn to the top left corner. Of course optimizations tend to be
tricky, and maybe do not compare with the cost/usability of a real DIB
engine. Maybe DirectDraw can be optimized too, by moving the depth conversion
from GetDC calls to surface locking. This would only shift the problem, but
if DDraw can read the state of the DIB section it could choose the most
efficient solution depending on the behavior of the game.
Another thing that should be checked before starting is if a fluent transition
is possible. For example, when a new dibsection DC is created, create a
classic dib section and a DC using the server. If the app does something the
new code can't do yet, load the data into the server and use the existing
X-Server GDI code. This way a fluent transition is possible, with
implementing the important calls first, then adding rare things while still
keeping full functionality.
Just some thoughts from my side. If you want this as a SOC project you will
need some menthor, and I think Alexandre is the only one who can do that for
implementing a DIB engine :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070301/e34d45e3/attachment.pgp
More information about the wine-devel