DIB Engine & GSoC

[Stefan Dösinger]

Am Donnerstag 01 März 2007 14:03 schrieb Benoit Pradelle:
> Hi,
>
> 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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070301/e34d45e3/attachment.pgp