http://bugs.freedesktop.org/show_bug.cgi?id=27254





--- Comment #2 from Alan <alan...@auckland.ac.nz>  2010-03-22 18:49:55 PST ---
(In reply to comment #1)
> > EXT_framebuffer_object.xml specifies that BlitFramebufferEXT
> > to be hidden while BlitFramebuffer is exposed as described in
> > ARB_framebuffer_object.xml, is that intentional?
> 
> This is reasonable, at least.  The Linux OpenGL ABI only requires
> that OpenGL 1.2, GLU 1.3, GLX 1.3, and ARB_multitexture symbols be
> available.
> 
> I refer you to the ABI, particularly section 3:
> 
>   http://www.opengl.org/registry/ABI/#3
> 
> See especially 3.4, 3.5, and 3.6.
> 
> > As GL_EXT_framebuffer_blit is supported since 6.5, I would have
> > thought that BlitFramebufferEXT should be defined in the library.
> >
> > It is unfortunately that when I test some of the functions using
> > MESA, I need to get a pointer to glBlitFramebuffer and when I test
> > it on an older piece of hardware then I need to get a pointer to
> > glBlitFramebufferEXT.
> 
> Sorry; this is how OpenGL is specified.  As you can read above,
> exposing glBlitFramebuffer is an implementation courtesy.  An argument
> could be made that nothing above GL 1.2 should be exported, so that
> developers like you and I would more quickly ascertain that we are
> writing invalid code!  That'd probably be a bad idea though, because
> a lot of `in the wild' code is likely to break if we remove all those
> entry points.
> 
> Anyway, the only valid way to get glBlitFramebuffer, or any extension
> really, is to load it dynamically.  This is why I recommend GLEW :)
> 

I agree with what you said and have planned to use GLEW, this gives me extra
motivation to use it ^_^ 
I guess I am just curious why this one is left out as all the other GL calls we
use in our software are included in Mesa's libGL, especially when
BlitFramebuffer is just an alias to it.

Anyway, thanks a lot. Once we get GLEW going here then I probably won't care
much about it.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to