DIBEngine

Wine requires a DIB engine (part of the display subsystem that, when pointed at screen memory, can serve as a flat-frame-buffer display driver) to properly handle Device Independent Bitmaps (DIB). In the Win32 API, an application can draw in a DIB via GDI calls or via direct memory access without any synchronization calls in between.

This implies a rather tight coupling of the graphics subsystem with the system memory, which is simply not present in a network transparent design such as X. This is a leftover of the Win16 API, I guess it seemed like a good idea at the time.

To emulate such behavior, we have to play memory tricks (by protecting the DIB memory) and switch between a 'GDI mode' and 'memory mode'. On each of these transitions, we have to copy the DIB to/from the X server. It works, but it is slow, especially over the network.

To fix this problem, we have to be able to emulate the GDI calls in software. This is what the DIB Engine is -- software rendering for the GDI calls.

Software rendering exists -- in fact, we are currently using the X server exactly for that: we copy the DIB to the server, translate the GDI call to an X request, and then we copy the result back. So the code exists, but it is in the X server. We need to copy it over to Wine, clean it up (the X code is not known for its neatness), and integrate it properly (from an architectural perspective) into Wine.

Note: The difficulty in this task is more integration with the current Wine codebase in an incremental and non-intrusive manner. Wine needs infrastructure for the DIB engine so that graphics operations without DIB support can fall back to X11.

A patch that dumps an entire DIB engine somewhere in the Wine tree is unlikely to be accepted (that has already happened!). It needs to be added in an incremental manner, without breaking working functionality.

See also:

• bug 421

CategoryToDo