[PyOpenGL-Devel] [ pyopengl-Bugs-2727274 ] glDeleteFramebuffersEXT Bug

[SourceForge.net <no...@so...>]

Bugs item #2727274, was opened at 2009-04-02 15:46
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2727274&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v3.0.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Francois Lagunas (flagunas)
Assigned to: Nobody/Anonymous (nobody)
Summary: glDeleteFramebuffersEXT Bug

Initial Comment:
The glDeleteFramebuffersEXT does not seem to work. The bug lead to an opengl "out of memory" error when allocating and disallocating a large number of fbos (~ 200 ).
In the attachement, a C++ version is included for comparison : the fbo id is recycled and then reused after glDeleteFramebuffersEXT is called, but not in the python version.
This is true for at least the 3.0.0 version .


----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-07-18 19:18

Message:
Running your original code on Linux AMD64 with the PyOpenGL bzr head, the
code works and the IDs are recycled (that is, no silent failure observed). 
Wrappers have also been added so you can pass any of the raw uint, an array
or the list as a single value to the delete operations.  ARB version has
been similarly wrapped.

----------------------------------------------------------------------

Comment By: Francois Lagunas (flagunas)
Date: 2009-04-02 16:48

Message:
My bad but ... 
You have to call the glDeleteFramebuffersEXT this way :

fbo_id0, fbo_id1 = EXT.glGenFramebuffersEXT(1)

glDeleteRenderbuffersEXT (1, numpy.array(fbo_id0)) 

or

glDeleteRenderbuffersEXT (2, numpy.array([fbo_id0, fbo_id1]))

and not

glDeleteRenderbuffersEXT (1, [int(fbo_id)]) 

which fails silently ...

The doc is very sparse on the subject, and the fact that it fails silently
is not very cool ...




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2727274&group_id=5988