thunderbird2k at gmx.net
Fri Nov 14 03:43:48 CST 2008
> В сообщении от Thursday 13 November 2008 13:22:07 Massimo Del
> > Sergey Novosyolov ha scritto:
> > > I've already started working on it about 3 months ago and released
> > > 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
> > >> 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
> > >> => 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
> X11DRV functions directly.
> If we operate with memoryDC GDI calls DIB functions and then uses BitBlt
> 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
More information about the wine-devel