Patches / a proposal for the mystic DIB engine

Alexandre Julliard julliard at winehq.org
Thu Apr 12 05:41:15 CDT 2007


Felix Nawothnig <flexo at holycrap.org> writes:

> 2. Export LockDIBSection/Unlock to gdi32.
>
>    Adding more exports is not nice but there really is no way around
>    that, right?

No, LockDIBSection is a driver internal detail, gdi32 has no business
knowing about this.

> 3. Move dc->funcs to dc->physDev->funcs. Many changes but mostly
>    mechanical work.
>
>    Rationale: This really belongs there. And I need it. :)

No it doesn't, physDev is an opaque structure as far as gdi32 is
concerned. Data needed by gdi32 belongs in the DC structure.

> 4. Now we write dibdrv.c for now just containing DIBDRV_Install
>    and DIBDRV_Remove. That function will go through the physDev->funcs
>    list and overwrite each function pointer which is actually
>    implemented with DIBDRV_PutPixel(), whatever.
>
>    DIBDRV_Install/DIBDRV_Remove will be called from
>    BITMAP_SelectObject() when we switch from non-DIB to DIB vice versa.
>
>    Note that we can't use DRIVER_load_driver here because of the
>    wanted "forward to original driver when not implemented".
>
>    For this we will need to extend the "for DIB objects" part in
>    BITMAPOBJ by
>
>     const DC_FUNCTIONS *orig_funcs;
>     DC_FUNCTIONS        local_funcs;
> 	
>    where orig_funcs to the old physDev->funcs and the new physDev->funcs
>    points to &bmp->local_funcs.

You certainly don't want to store the full function table in the
BITMAPOBJ, it will be the same for all bitmaps. All you need is one
function table for the DIB driver and one for the normal graphics
driver.  Forwarding to the graphics driver can be done privately in
the DIB driver, gdi32 doesn't need to know about it. And you probably
want a separate physDev pointer for it, you'll need to maintain state
for DIBs too.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list