Forgot the link: http://opensg.vrsource.org/trac/changeset/1826
On Tue, Mar 17, 2009 at 8:12 PM, Allen Bierbaum <[email protected]> wrote: > This is the change we came up with. Probably not pretty, but it works > for now. We welcome any comments/ideas for improvements. > > In our case this takes in memory image consumption down from 600MB to > around 5-10MB or less. > > -Allen > > On Tue, Mar 17, 2009 at 12:39 PM, Allen Bierbaum <[email protected]> wrote: >> Will do. >> >> Just to quantify what we seeing, we now have an application that takes >> up 1GB with 600MB used for OSG::Image objects that are not needed >> after they get uploaded. We will try to fis it up. >> >> -Allen >> >> On Tue, Mar 17, 2009 at 12:01 PM, Dirk Reiners <[email protected]> >> wrote: >>> I would keep the image around, just clear the data. >>> >>> >>> >>> On Mar 17, 2009, at 9:17, Aron Bierbaum <[email protected]> wrote: >>> >>>> Does anyone have any more thoughts on how to approach this problem? We >>>> started working on a simple solution that just uses a >>>> freeImageAfterUpload flag but ran into some difficulty because it >>>> appears the current code tries to access to OSG::Image for other >>>> parameters such as dimension etc after we would have freed it. I will >>>> be working more on the today so if anyone has ideas please let me >>>> know. >>>> >>>> Thanks, >>>> Aron >>>> >>>> On Wed, Dec 31, 2008 at 3:50 PM, Allen Bierbaum >>>> <[email protected]> wrote: >>>>> 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 >>>>> >>>> >>>> --- >>>> --- >>>> --- >>>> --------------------------------------------------------------------- >>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >>>> are >>>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly >>>> and >>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>>> development >>>> software that enables intelligent coding and step-through debugging. >>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>>> _______________________________________________ >>>> Opensg-users mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/opensg-users >>> >>> ------------------------------------------------------------------------------ >>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development >>> software that enables intelligent coding and step-through debugging. >>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>> _______________________________________________ >>> Opensg-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/opensg-users >>> >> > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
