Speed of gdi vs opengl DirectDrawRenderer

[Ken Thomases]

On Feb 19, 2015, at 2:12 PM, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:

> I had a problem with Majesty Gold HD running at glacial speed on my
> machine (quad Core i5 2.9GHz, NVidia GeForce GT 750M 1GB, OS X 10.9.5).

> … are there any things I can try to narrow down why the gdi
> renderer is so much faster? I didn't immediately see where it blits
> things actually to the screen.

GDI32 rendering goes to an in-main-memory window surface (backbuffer).  USER32 tells the Mac driver to flush that window surface to screen at certain points, but the Mac driver implements that asynchronously.  Basically, the flush operation queues a request to the Cocoa main thread to call [window.contentView setNeedsDisplayInRect:theDirtyRect].  The Wine thread is allowed to go on as soon as that request is queued.  It doesn't wait for the view to be actually marked as needing display, let alone for Cocoa to get around to actually displaying it.

When the Cocoa main thread does go to display the view, it locks the window surface and creates CGImages from its data and draws those to the window.  Then it unlocks the surface.  But those draw operations are not flushed immediately to screen while that lock is held.  So, the surface lock should not be held while Cocoa waits for the GPU or the Window Server refresh cycle.

Basically, GDI32 and USER32 can overdrive the drawing loop without having to wait for the GPU or the refresh cycle.

See if the game has a setting for disabling vsync.  If it doesn't, try setting:

[HKEY_CURRENT_USER\Software\Wine\Mac Driver]
"AllowVerticalSync"="n"

Does that help?


Others would understand better why the OpenGL renderer is slow.  Does your system support 16-bit display modes?  Is the game/wined3d actually switching it into one of those?

-Ken