[osg-users] OSG_TEXTURE_POOL_SIZE issue

[Wojciech Lewandowski]

Here is the repro code. I made it as simple as I could. Please note that it
only shows the core of the problem. One may argue that with this limit I
set here in example, we have no room for last RTT texture anyway. But the
problem will show up too if I increase the TEX_POOL limit to store 3 RTT
textures, but will initially fill the memory with other textures (with
images of different resolution or format). Once memory size of these
initial textures + newly added RTT passes TEXTURE_POOL_SIZE, the problem
will show up when one of the RTTs is added later...

Cheers,
Wojtek

2016-10-09 20:17 GMT+02:00 Wojciech Lewandowski <w.p.lewandowski at gmail.com>:

> Could you modify one to OSG examples to illustrate the problem so
>> others can reproduce it.  I have paged databases to test against, but
>> not the particular FBO usage that you are using along with it.
>
>
> Ok. I'll try to make a repro. I do believe however that in our case we do
> not attach images to FBO but empty textures. And those textures are
> scraped. I wrote 'I believe' because its not all my code, maybe someone
> attached images somewhere to debug. I will double check  and include this
> case in repro if its true.
>
> Wojtek
>
> 2016-10-09 14:47 GMT+02:00 Robert Osfield <robert.osfield at gmail.com>:
>
>> On 9 October 2016 at 11:27, Wojciech Lewandowski
>> <w.p.lewandowski at gmail.com> wrote:
>> > Hi, Robert. Thanks for quick response.
>> >
>> >> Perhaps a flag in osg::Texture might be appropriate to declare whether
>> >> this Texture is
>> >> suitable for reuse or not.
>> >
>> >
>> > Perhaps. However, I have the feeling that this flag would be equivalent
>> to
>> > checking if (image != NULL) in current 3.5.5 OSG code base context. I
>> don't
>> > see how already assigned and active image-less texture coud survive such
>> > Take operation without a callback (or similar mechanism) to let texture
>> > owner refresh it before apply.
>>
>> In design of the texture pool assumes that if the image is NULL then
>> the texture can't be taken.  If this isn't being upheld then it looks
>> like a bug.
>>
>> > Considering need for supporting multiple
>> > contexts and fact that such refresh callback would require action in
>> draw
>> > stage, I see this postulate (for a refresh callback) as hard to
>> implement
>> > and probably not used by users in practice. So I conclude that (image !=
>> > NULL) is probably a sufficient check for now ;-). Did I skip some use
>> case ?
>>
>> One case would be people assigning an osg::Image to textures that are
>> assigned to an FBO.
>>
>> FYI, I'm just quickly checking posts, I'm not working at a dev
>> computer so I can't review code or spend long things deeply about a
>> topic. so my response are really preliminary :-)
>>
>> Could you modify one to OSG examples to illustrate the problem so
>> others can reproduce it.  I have paged databases to test against, but
>> not the particular FBO usage that you are using along with it.
>>
>> Robert.
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20161009/88c27cd2/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: texture_pool_repro.cpp
Type: text/x-c++src
Size: 2819 bytes
Desc: not available
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20161009/88c27cd2/attachment-0003.cpp>