DIB Engine & GSoC
ze_real_neo at yahoo.fr
Thu Mar 1 15:49:25 CST 2007
First thank you for your very complete answer,
I'm not really familiar with Wine (and the Windows API) and I don't
understand why do you think that it will be such an hard work. For me,
the work will consist in redirect the GDI calls from the X11
pseudo-driver to some new functions which will draw circles, lines,
etc.. over DIBs.
Do I misunderstand the work to do or under evaluate it ?
And I've understand by reading this mail-list how important are
regression tests and fluent transitions in functionalities for Wine.
Stefan Dösinger a écrit :
> 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 :-)
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
More information about the wine-devel