DIB Engine & GSoC

[Benoit Pradelle]

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:
>   
>> 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 :-)
>
>   


	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com