Hi Lionel,

I have just reviewed your changes and don't feel that it's an elegant
solution, and could easily lead to confusion and misuse down the line.

I haven't yet settled upon a solution but it feels to be that that the
GLObjectBuffer::BufferEntry data structures themselves should be
marked as no longer required, and once all the BufferEntry objects
have been used and no longer required have the whole GLObjectBuffer
released.  Perhaps simply deleting the BufferEntry would be sufficient
for this purpose, this way once the GLObjectBuffer has an entry
_bufferEntries it's should be able to be released safely, or perhaps
the modifiedCount could be used in conjunction with a copied count.

Thoughts?
Robert.

On 10 January 2013 15:01, Lionel Lagarde <[email protected]> wrote:
> Hi,
>
> Happy new year !!!
>
> Here is the fix for the multiple PBO creation/destruction happening when
> paging textures.
>
> The problem was:
>
> the pager loads X.osgb containing the textures A (A.png), B (B.png) and C
> (C.png).
> the incremental compile operation sets the PBO of the images (the same PBO
> for every image)
> during the database compilation, for each textures:
>    a GL buffer object is created and the three images are uploaded into
>    the GL buffer content is used to as source of glTexImage
>    because the "copy data and release GL buffer object" member of the images
> buffer object is true, the GL buffer object is released
>
> i.e. every texture compilation creates/uploads images/destroys the GL buffer
> object
>
> In this fix, during the first texture compilation, the GL buffer object is
> created and the images are uploaded. During the last texture
> compilation, the GL buffer object is destroyed.
>
> I introduced a new counter in GLBufferObject: how many buffer entries of the
> buffer have not been used.
> Because the counter is in GLBufferObject, it is only valid for the context
> of the GL buffer.
>
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to