Hi,
I'm getting ready to implement the Quartz Driver. For those of you who don't know, this is a special graphics driver that only works on Mac OS X, and uses its native Core Graphics (aka, Quartz) system to draw.
But before I can do this, there are two things that need to be done:
1. Wine currently assumes that the current graphics driver is the X11 driver. It directly GetModuleHandle()'s winex11.drv in order to call driver functions. This needs to be fixed. 2. The driver interface needs to be standardized.
I can fix the first problem by adding a Wine-specific export to GDI32, then updating all the winex11 clients to call this function, but the second problem will make writing a non-X11 driver problematic. The GDI and USER interfaces are already somewhat standardized, but the reason many clients call winex11.drv directly is to call the "Thread-Safe X11" locking routines. Also, Explorer calls winex11 to create the desktop and notification area ("systray") windows.
Therefore, I propose this interface. It's largely based off of winex11, but with some small modifications. It's attached to this mail. What do you think of this?
And don't tell me that we need a DIB engine before I get started on winequartz. I intend to use Mac OS X native APIs (like Core Image) to accelerate DIBs, in much the same way winex11 uses Xrender.
Chip
I'm doing my own (non-X11 and not a Quartz one) version of a graphics/ user driver, and the interface is quite stable. Only a few minor changes were done over the period of ~6 months.
Also, if I don't mistake, the specific winex11 calls from explorer are not needed anymore.
WBR, Aleksey Bragin.
On Apr 21, 2010, at 12:40 AM, Charles Davis wrote:
Hi,
I'm getting ready to implement the Quartz Driver. For those of you who don't know, this is a special graphics driver that only works on Mac OS X, and uses its native Core Graphics (aka, Quartz) system to draw.
But before I can do this, there are two things that need to be done:
- Wine currently assumes that the current graphics driver is the X11
driver. It directly GetModuleHandle()'s winex11.drv in order to call driver functions. This needs to be fixed. 2. The driver interface needs to be standardized.
I can fix the first problem by adding a Wine-specific export to GDI32, then updating all the winex11 clients to call this function, but the second problem will make writing a non-X11 driver problematic. The GDI and USER interfaces are already somewhat standardized, but the reason many clients call winex11.drv directly is to call the "Thread-Safe X11" locking routines. Also, Explorer calls winex11 to create the desktop and notification area ("systray") windows.
Therefore, I propose this interface. It's largely based off of winex11, but with some small modifications. It's attached to this mail. What do you think of this?
And don't tell me that we need a DIB engine before I get started on winequartz. I intend to use Mac OS X native APIs (like Core Image) to accelerate DIBs, in much the same way winex11 uses Xrender.
Chip <winegdrv.drv.spec>
-
Aleksey Bragin -
Charles Davis