On Wed, Dec 31, 2008 at 8:14 AM, Gerrit Voss <[email protected]> wrote:
>
> Hi,
>
> Allen Bierbaum wrote:
>> Any ideas on this one.  I looked into it a bit and the behavior I am
>> thinking about is something like this:
>  >
>>
>> - After texture has been bound, the system automatically sets image to NullFC
>> - This frees the image fc memory
>> - The code detects that the system was the one that set the image to
>> NullFC and checks if the "allow null flag" is set. If so, it goes
>> about it's merry way.
>>
>> This means that even if the flag is set, if the user sets NullFC, the
>> system does it's normal behavior of unbinding the texture.
>>
>> Before I put time into implementing this though, does this behavior
>> make sense and do people think it would be valuable in OpenSG?  (ie.
>> will a patch be accepted)
>
> I'm a little bit sceptical that we can get away with a simple solution
> like this. E.g. it will break for cluster and par drawing environments.
> And I see it breaks your lod stuff as you will unload the textures
> when switching LOD's but as you already destroyed the image you
> won't be able to reload them if you ever need a particular LOD again.

Agreed.  I don't propose to know how to make this work in the general
purpose case for all uses.  Thus I don't think it should be enabled by
default.  I think it only makes sense for users that know exactly how
the application will behave and are acting accordingly.

If anyone has a smart idea for how to handle cluster and parallel
rendering, I am all ears, but in the meantime I am just looking for
something to allow our application to run without churning through all
the memory in the system. :)

-Allen

> I'm tossing things around just now.
>
> kind regards
>   gerrit
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Opensg-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>

------------------------------------------------------------------------------
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to