DIB Engine - New approach

[Jesse Allen]

On Tue, Apr 14, 2009 at 1:22 AM, Massimo Del Fedele <max at veneto.com> wrote:
> 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 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.
>


What about other drivers?  Is the DIB driver going to know how to
handle the others then?

Does it even make sense to keep the DIB engine a driver anymore?

Jesse