Am Dienstag, 25. April 2006 18:03 schrieb Stefan Dösinger:
Hi,
I'm with you. This is the single most annoying regression I've ever seen in Wine. As this seems to be top-priority anyway, it's one of the best possible SOC candidates (this and a DIB engine), given that most regular devs that might be able to fix the regression don't seem all too motivated to really touch that issue. Who cares if games take a slight performance hit, if a fix would unbreak lots and lots of applications that used to work - an acceptable tradeoff, IMHO...
If you are talking about the pbuffer way, and I understand this correctly, then this wouldn't be a slight hit, but a major performance loss. I think the solution would be to render to an offscreen texture. This would mean to copy the rendered image back to main memory, copying it through the cpu and then sending it back to the card. For a 1024x768x32 image this are 3 megabytes per frame.
AFAIK, there are four targets OpenGL can draw to on X: X windows, Pbuffers, FBOs or GLX pixmaps. EXT_framebuffer_object should be the most interesting approach, as it's supposed to somewhat similar to Pbuffer rendering, but supposed to be more portable and faster: "This extension defines a simple interface for drawing to rendering destinations other than the buffers provided to the GL by the window-system." But I guess a FBO or a GLX pixmap would still introduce a similar performance hit compared to Pbuffer rendering?
Forest Hale (and Lionel Ulmer) suggested a different, but probably more hacky and difficult approach (from http://wiki.winehq.org/OpenGL): "I would recommend overriding the glViewPort and glScissor calls, as well as gl[En/Dis]able GL_SCISSOR_TEST, and arrange the glViewPort for the proper projection for rendering, but use glScissor to set the region that can be rendered in the current DC, also there should be no slowdown from having scissor test permanently on."
Another practical way to handle the issue would be to partially restore the old WM handling, and draw only OpenGL viewports to seperate X windows (if it's possible for Wine to determine what viewport uses OpenGL).
The current directdraw code handles it this way for windowed direct3d rendering. I can get about 20 fps with moto racer 2 in windoed mode at 512x384 on my radeon mobility M9. If the game wouldn't cap the speed at 35fps, I'd expect it to achieve 200fps on the same hardware(it's a very old Direct3d1 game).
For fullscreen mode we could still use the normal rendering way, but windowed apps still wouldn't work very well.
Sorry, I don't get this. Windowed applications should not be affected? There is no problem with windowed OpenGL applications, they are not affected by bug 2398 anyway. Only applications with embedded OpenGL viewports are affected, so a workaround would only need to target embedded viewports...?