General Category > Ongoing Anim8or Development

High Memory Use and Slow Playback Problem

(1/5) > >>

slex:
unfortunately, I had few crashes in scene editor when there are many steps with loaded object consisted of a mix of subdivision+mesh+textures and it's figure and sequence with multiple instances included in a scene, my laptop has 4gigs of ram so I guess it isn't computer. I've noticed in task manager that program becomes slow when there are too many undo steps, it starts with 25MB, after loading the project it goes to 50MB and with each new movement it adds few megabytes of ram in the task manager.
Maybe increasing undo buffer to 500MB or even more could solve the problem or limiting the undo-redo to maximum of let's say 15 steps so it 'forgets' older steps?

Steve:
slex: My guess is that like Anim8or isn't freeing the undo history memory once it surpasses the limit.  It's supposed to delete the earliest data when this happens but it doesn't seem to be doing that. I'll see if I can find the cause.

slex:
Actually, here is a prtscr. memory goes way beyond 100MB, I did very big number of steps in a scene  :o

Steve:
The undo code seems to be working properly.  It can use a bit more that the limit, but just one undo record more at the most.  When it frees history it deletes the earliest records until it is just *above* the limit instead of just *below* it.

I don't see why your project should be that big.  Are you using a lot of textures, especially large ones?  How many scenes, etc are there?  Have you been runnning Anim8or for a long time and the size keeps getting bigger?  That *could* mean a memory leak.  I always develop using a debug mode that checks for leaks and I don't know of any, but that doesn't mean there aren't any.

Note that the number used for the max size of the undo buffer is just for that, the undo buffer.  There are many other things that can use much more memory than this.  All geometry is stores at least twice (for the model and for the OpenGL buffers), textures are stored as full size images (i.e. a 4k by 4k RGB .jpg file might use only a bit 1 or 2 MB on disk but in memory it uses almost 100 MB, including mipmaps), and subdivision meshes, while they are very compact on disk, can grow quite large when expanded into memory.

However keys for animation do not use very much memory.  I doubt that the length of the animation makes much difference.

cooldude234:

--- Quote from: Steve on March 11, 2016, 02:17:28 am ---textures are stored as full size images (i.e. a 4k by 4k RGB .jpg file might use only a bit 1 or 2 MB on disk but in memory it uses almost 100 MB, including mipmaps), and subdivision meshes, while they are very compact on disk, can grow quite large when expanded into memory.

--- End quote ---

And he is not kidding either,
I made a drawing application that handled large images (I made it just for quick tests) and needed fully uncompressed images in memory so a image would take the full space it required. A 10000 x 10000 32 bit (rgba) sized image took up around 400 Mb in ram.

8 bits per channel = 32 bits
32 / 8 = 4 bytes = one pixel
4 bytes * 10,000 * 10,000 = 400,000,000 bytes
400,000,000 / 1000 = 400,000 Kilobytes
400,000 / 1000 = 400 Megabytes

Also I was using (one of) the oldest opengl function for taking image data from Ram and uploading it to the Vram (glTexSubImage2D) in real-time. That probably spawns nightmares in Steves dreams :P

Navigation

[0] Message Index

[#] Next page

Go to full version