Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

[Leon Freitag]

> Does that work any better?
> The patch works wonderfully! Thank you very much!
> The only thing is that you have to modify the Makefile.in in the opengl32 
> directory and add "ntdll" to the libs list.
> Well, to make this work better, one would need a two-tiered approach:
> = use thread-local variables to check if it's a 'special' buffer or not
>   (like this patch does)
> = only do this check on GL APIs that actually modify or read from the frame 
> buffer (basically stuff like glClear, glEnd, gl(Read|Write)Buffer, ...).
> The last is easy to do for 'core' stuff, a bit harder for extensions though.
> But anyway, this is mandatory if one day we want to fix the 'windowed' 
> OpenGL code properly (whatever the method we choose as long as we do not 
> have the GLX extension exporting the clip list feature to the application).

I don't think it would be that hard to realize. Right now we have the 
ENTER_GL() macro that gets called before each opengl call (see opengl_ext.c 
and norm.c) where the check and sync occurs. One solution would be to make 
two enter_gl functions -- one with the check and one without, and hardcode 
some database with the function list in the script that generates the files.

This patch does already a great job for fixing Huw's regressions, and me and 
many Wine users would greatly appreciate its merge into Wine tree.

Leon

opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

[Lionel Ulmer]

On Mon, Mar 20, 2006 at 05:09:53PM +0100, Leon Freitag wrote:
> I don't think it would be that hard to realize. Right now we have the
> ENTER_GL() macro that gets called before each opengl call (see opengl_ext.c 
> and norm.c) where the check and sync occurs. One solution would be to make 
> two enter_gl functions -- one with the check and one without, and hardcode 
> some database with the function list in the script that generates the files.

I agree, not hard at all to do, but the database needs to be maintained and
it would mean that upgrading to new extensions would not be 'automatic' as
it is now as one would need to review manually all new extensions to check
the one that can modify / access the FB.

       Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/