I haven't tried your solution yet. But I'll give you some feedback as
soon as I did.
Best regards,
Marco
>>> Carsten Neumann <[EMAIL PROTECTED]> 24.09.2008 18:31 >>>
Hello Marco,
Marco Spoerl wrote:
> Hello Carsten,
>
> Thanks for your modified test app. First up, I think I have to
mention
> that we're using the 1.8 release here, not something fresh from the
> repository. So I had to tweak it back a little bit to work with our
> version of the library.
>
> The following numbers are simply taken from the task manager.
>
> 29.000K when running idle
> 57.000K before exiting the leak function
> 31.000K after exiting the leak function
>
> Increasing the number of iterations to 1000, I get the following
> numbers.
>
> 29.000K when running idle
> 299.000K before exiting the leak function
> 61.000K after exiting the leak function
hm, that is indeed a lot of memory.
I've modified the program (attached) so that it now uses only one
texture and image [1] for grabbing and writes the result to disk (I
enabled readBuffer on the FBOViewport). Of course that means that the
grabbed images do not remain available for rendering (at least not
without loading them from disk again), neither in texture nor main
memory.
With that change I don't see a massive increase in memory consumption.
So my guess would be that what you see above is (at least a good
portion
of it) memory allocated by the graphics driver for the textures.
> So, from my point of view, I'm still seeing the problem. Maybe I
have
> to use a newer version of the library? In that case, I'd be grateful
for
> any tips how to get a reliable revision.
> Or do I have to change the way
> I grab my textures? In our application, that preprocessing step
easily
> involves tens of thousands of texture grabs.
The best way for grabbing the textures depends on how you intend to use
them and the resources available. If you need all of them at once for
rendering there is probably not much that can be done, but to keep them
in texture memory, i.e. having a TextureChunk and Image for each of
them. If you only need a subset for rendering you could use a small
number of chunks and place the images you want to use in them (would
still require lots of main memory for all the images, but less texture
memory).
The last alternative is pretty much what the program does: use one
chunk
and image and store the data on disk. You could later load in the
relevant images and place them in textures for rendering.
Hope it helps,
Carsten
[1] that is controlled with the SINGLE_IMAGE define near the top of the
program
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
