DIB Engine

Sergey Novosyolov chi at etersoft.ru
Sun Nov 16 09:30:16 CST 2008


В сообщении от Friday 14 November 2008 12:43:48 Roderick Colenbrander 
написал(а):
> > В сообщении от Thursday 13 November 2008 13:22:07 Massimo Del
> > Fedele
> >
> > написал(а):
> > > Sergey Novosyolov ha scritto:
> > > > 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
> > > >> converting
> > > >>       issues.
> > > >
> > > > So the conception of new strusture of DIB ENgine inside GDI is needed
> > >
> > > The question is if we should support native drivers or not, other than
> > > winex11 or wineps. For winex11, we're using native rendering functions,
> > > for wineps we're just translating GRE calls to ps code directly, no
> > > need to convert forth and back. Other stuff would be raw printing, for
> > > example, using native drivers.... but are they really needed ?
> > >
> > > AFAIK the bottleneck now is the double conversion of DIB-X11 DDB-DIB,
> > > in order to be able to use X11 rendering functions, so the point 3. I
> > > don't understand your point 1; why convert DDB to DIB ? Driver should
> > > render directly into DDB. GDI calls can be directed to native ones.
> > >
> > > I see it this way (but I could be wrong) :
> > >
> > > 1) Application uses a DIB format, rendering should be done by DIB
> > > driver, conversion is needed only to display it. This is what by now is
> > > done with 2 conversions between DIB-X11-DIB formats.
> >
> > As i see if we operate with Display DC we no need to convert and GDI32
> > calls
> > X11DRV functions directly.
> >
> > If we operate with memoryDC GDI calls DIB functions and then uses BitBlt
> > if
> > needed to reflect memoryDC operations on teh display
> >
> > > 2) Application uses accelerated opengl, for example; it must (afaik)
> > > use native format and functions to render it. No need to convert
> > > anything.
> >
> > what do you mean "native format"? is it connected with GDI calls?
> >
> > > 3) Printer drivers. For ps, they're rendered translating GDI calls into
> > > postscript code, for other format the driver should do the rendering.
> > > Again, no conversion needed.
> >
> > I agree
> >
> > > So, I don't understand why to have DIB engine INSIDE GDI. Function
> > > pointers could handle the correct driver calls depending on DIB (or
> > > DDB) format.
> >
> > DIB is Device Independent Bitmap so DIB functions would be include those
> > functions which implemented the same independ of device
> >
> > > Max
>
> From reading all your mails I get the impression that Etersoft is also
> doing some work on the DIB engine. What work has Etersoft done on this
> area? It might be wise to post the code somewhere for review before the
> wrong direction is taken again and it might prevent code duplication.
>
> Roderick

We have received Huw Davies and Jesse Allen gits with their versions of DIB 
and continued working on it. But we're planning to change DIB Engine 
structure in these cases:

1. Releasing DIB Engine functions inside GDI.
 2. Releasing interactioin DIB Engine with other drivers (such as X11, PS 
etc.)

Today we've developed some DIB functions iwithout cnaging DIB driver 
structure. The main structure of DIB is just an idea and it was not changed 
yet.



More information about the wine-devel mailing list