chi at etersoft.ru
Wed Nov 12 06:27:13 CST 2008
В сообщении от Wednesday 12 November 2008 14:00:38 Massimo Del Fedele
> I recently had a chat with Dan Kegel about the way to contribute and
> start hacking on a DIB engine. I grabbed Huw Davies and Jesse Allen's
> repositories and started looking at them.
> As it'll be an hard (and long) work, I'd like to know some opinions on
> how to proceed and propose an idea on how to have it introduced in
> mainstream without breaking stuff.
> The idea is, for now, JUST an idea and I still don't know if it'll be
> possible, but I guess yes.
> So, I was thinking on :
> 1) Try to join best stuffs of both repos of Huw and Jesse.
> 2) Add the environment variable DIBENGINE which could have 3 different
> values (or be missing) :
> missing DIBENGINE env var or
> DIBENGINE=NONE New dib engine will not be used, back to X11DRV
> DIBENGINE=FORWARD Unimplemented stuffs forwarded to X11, the rest
> using new dib engine code
> DIBENGINE=FULL use just dib engine code and shows FIXMEs for
> unimplemented stuffs
> The first would allow to insert dib engine in main stream without
> breaking anything, the last would allow to see what's more important to
> implement. The middle one (FORWARD) would allow to check if something
> breaks during the transition, and use the developed parts.
> 3) Stop and wait till it's put on mainstream, so more people could
> The doubt is if it'll be possible the mixed approach, forwarding
> unimplemented stuffs to X11, but I think so.
> Is it an acceptable way to proceed ?
I've already started working on it about 3 months ago and released some
functions inside DIB Engine. But now we're thinking about release DIB inside
GDI32 as Detlef Riekenberg proposed:
On 9/29/08, Sergey Novosyolov <chi at etersoft.ru> wrote:
>> The first thing, i like to see is a Design in the correct way:
>> Inside gdi32 while using Eng* and friends.
>> (Needed by Printer drivers, and any Display driver including mirror /
>> remote display drivers)
> why can't we release DIB-Engine as own driver? GDI32 functions are main and
> GDI32 calls driver functions in dependence of which type of DC we have
> (printer DC, Xwindow HDC or DIB DC)
>Any Driver can call the Graphic Rendering Engine (GRE)
>to do parts (or all) of the rendering (and native driver do that):
>1: DDB (Driver managed: using any driver specific format)
> (The Driver should do Everything. When the driver call the GRE,
> the DDB is converted to a DIB, GDI renders into the DIB and then
> the DIB is converted back to a DDB)
> => like our winex11.drv and wineps.drv
>2: DDB (GDI managed: using DIB format)
> (The driver render, what the driver want to render with hw-support
> and can call the GRE for all the other rendering without converting)
> => Needed for native printer drivers / mirror drivers or
> OpenGL accelerated rendering (stefan did some experiments)
> (GDI renders everything)
> => The current Code is using a X11-DDB (Driver Managed) with
So the conception of new strusture of DIB ENgine inside GDI is needed
More information about the wine-devel