P.S. Isn't it better to use pkg-config to check where the libs are located
anyway?
Leon
pgpbKZ8HlkpCr.pgp
Description: PGP signature
My first impressions:
1) Doesn't compile here:
audio.c: In function ‘OpenAL_WaveClose’:
audio.c:636: error: void value not ignored as it ought to be
because alcCloseDevice() is declared here as void (my openal version is
1.0.20051129)
2) It'd be better to convert ALC errors from FIXMEs to ERRs.
> AC_CHECK_HEADERS(\
>+ OpenAL/al.h \
>+ al/al.h \
> AudioUnit/AudioUnit.h \
> CoreAudio/CoreAudio.h \
> IOKit/IOKitLib.h \
Your patch checks for OpenAL headers only in these places. However my distro
(Suse 10.1) puts openal headers to AL/ instead of al/ and so configu
Am Dienstag, 4. April 2006 14:49 schrieben Sie:
> Leon Freitag wrote:
> >> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
> >> patch but it was rejected.
> >
> > Well, try to resubmit it :) Or post it here, so that others could test
&g
Am Dienstag, 4. April 2006 14:49 schrieb Tomas Carnecky:
> Leon Freitag wrote:
> >> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
> >> patch but it was rejected.
> >
> > Well, try to resubmit it :) Or post it here, so that others coul
Am Dienstag, 4. April 2006 14:49 schrieb Tomas Carnecky:
> Leon Freitag wrote:
> >> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
> >> patch but it was rejected.
> >
> > Well, try to resubmit it :) Or post it here, so that others coul
> The BadMatch in X_GLXCreateGLXPixmap is another problem.. here you
> should get a BadMatch in X_GLXMakeCurrent.
That's true, this patch should only fix the BadMatches in glXMakeCurrent.
> BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a
> patch but it was rejected.
Well, tr
Someone mentioned earlier that the code in wgl.c in DescribeDrawable()
violates the GLX specification and therefore causes bogus return values for
the visualid. However this code has been already present before the
regression, but worked somehow. So the regression can't be caused by this
violat
P.S.
Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I
don't know if there are applications that draw opengl in multiple threads in
different contents, and if current code would make any problems with these.
Leon
pgpuVZzrHYLJW.pgp
Description: PGP signature
> 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 variab
> This is not a patch but rather partial reversal of the patch that caused
> this regression.
It's not a complete reversal though. That doesn't imply that it's not a fix.
Perhaps the original patch had a bug in it.
> -GLXDrawable drawable;
> -enum x11drv_escape_codes escape = X11DRV_GET_G
> I don't see any other way to speed this up the way it's being synced now,
the
> question is however, whether the apps really _should_ modify the bitmap on
> windows too (don't know whether they would try to draw controls onto the
> window and then it would be overdrawn by the opengl image; ap
> On Sun, Mar 12, 2006 at 05:44:57PM +0100, Leon Freitag wrote:
> > The patch
> > http://source.winehq.org/git/?p=wine.git;a=commit;h=13268261bbe0d4013937a
> >6a9804fbda378244512 has introduced an annoying performance regression
> > which affected all opengl games. (see
13 matches
Mail list logo
