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
