DIB Engine

[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
> 
>