DIB Engine - New approach (resent as first got lost...)

[Massimo Del Fedele]

The approach taken so far consisted in having 2 device pointers inside GDI32, one for dib engine and
the other for normal display driver.
This way had the disadvantage of having to keep in sync the DC with the right driver depending on
selected bitmap, which lead to many small changes spread along all gdi code; going deeper with
development this approach showed many limits and problems.

So I decided to start again from scratch with a completely different approach which is giving good
results and is quite less invasive on gdi32 code.
Instead of doing :

             -- DIB ENGINE
           /
GDI32 ---
           \ -- X11 DRIVER

I took this approach :

GDI32 -- DIB ENGINE -- X11 DRIVER

The (X11) display driver is loaded from inside the engine, which replaces it from gdi32 point of view.
The changes in gdi32 are *very* limited, just in driver.c code, making it to load (if desired) the
engine instead of normal x11 driver. No other changes needed. I added as usual the code allowing to
enable/disable the engine on request by registry and/or environment variable.
If the engine is not present or disabled, the driver loader falls back to usual behaviour.
The Engine then loads the X11 driver in init phase and acts as a gate depending on selected BMP,
forwarding to X11 driver all requests for DDB bitmaps and doing the job itself for DIB ones.

This approach showed many advantages, and I' almost ready converting all old code to it.
By now I'm posting here 3 patches (EDIT : posted on bug421 page, as here they disappeared....)
showing the approach; the posted driver is a simple pass-throu one,
so it just forwards all calls to X11 driver. The last patch of the series shows the forking behaviour
of DIB/DDB processing from inside the engine, but still forwarding all to X11.

I'd like some comments on the approach taken; on next days I'll post a more complete code with most of
the engine implemented.

Ciao

Max

[Reece Dunn]

2009/4/14 Massimo Del Fedele <max(a)veneto.com>:
> The approach taken so far consisted in having 2 device pointers inside
> GDI32, one for dib engine and
> the other for normal display driver.
> This way had the disadvantage of having to keep in sync the DC with the
> right driver depending on
> selected bitmap, which lead to many small changes spread along all gdi code;
> going deeper with
> development this approach showed many limits and problems.
>
> So I decided to start again from scratch with a completely different
> approach which is giving good
> results and is quite less invasive on gdi32 code.
> Instead of doing :
>
>            -- DIB ENGINE
>          /
> GDI32 ---
>          \ -- X11 DRIVER
>
> I took this approach :
>
> GDI32 -- DIB ENGINE -- X11 DRIVER

This looks interesting. Have you run it past Alexandre on IRC, as he's
the one that you need to convince?

- Reece

[Massimo Del Fedele]

Reece Dunn ha scritto:
> 2009/4/14 Massimo Del Fedele <max(a)veneto.com>:
> > The approach taken so far consisted in having 2 device pointers inside
> > GDI32, one for dib engine and
> > the other for normal display driver.
> > This way had the disadvantage of having to keep in sync the DC with the
> > right driver depending on
> > selected bitmap, which lead to many small changes spread along all gdi code;
> > going deeper with
> > development this approach showed many limits and problems.
> >
> > So I decided to start again from scratch with a completely different
> > approach which is giving good
> > results and is quite less invasive on gdi32 code.
> > Instead of doing :
> >
> > -- DIB ENGINE
> >          /
> > GDI32 ---
> >          \ -- X11 DRIVER
> >
> > I took this approach :
> >
> > GDI32 -- DIB ENGINE -- X11 DRIVER
>
> This looks interesting. Have you run it past Alexandre on IRC, as he's
> the one that you need to convince?
>
> - Reece

I still couldn't speak to him.... next days, maybe.
BTW, on bug421 page there's now a working engine with the new approach.
Porting of all functionality of previous engine is completed.

Patches should be now quite independent of wine release, as the changes to
core code are really minimal.

Ciao

Max