DIB Engine

Sergey Novosyolov 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
> contribute.
> 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 ?
> Ciao
> Max

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)

>3: DIB
>   (GDI renders everything)
>  => The current Code is using a X11-DDB (Driver Managed) with
>      issues.

So the conception of new strusture of DIB ENgine inside GDI is needed

More information about the wine-devel mailing list