SOC project

[Willie Sippel]

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...?

-- 
Willie Sippel

  ////////  |  Tritium Studios
 //         |  ______________________________
//// ///    |  http://www.tritium-studios.com

<willie at froq.net>