Kivy Atlas and Memory, 2D Graphics and Animation

[Horace Johnson]

After working with Kivy and it's atlas long enough, I realize the purpose of the atlas concept was defeated.  There's no point in excessing a bunch of sub-images if you're going to the hard drive every time.  You're in fact causing what's known on desktops as thrashing.  This is a major frame rate killer and virtually makes Kivy and almost obsolete API set for developing games.

My question is...  Granted there's something I don't know about....

Is there a way to store an atlas in ram (cache) and access the atlas and sub-frames from memory instead of hard drive (sd card)?  You can't convert the sub-images to textures but even if you could, that would also defeat the purpose, hence you want to only store one big texture....the atlas.

I really don't see a way to have multiple 2D animations from multiple instances in a Kivy game, running on a hand-held device. Of course there's no issues on a desktop or laptop.  A basic Android device only allows for 16 texture units of 4096.

Animations require frames (at least 15 a piece) and because of that, one could easily cause a crash on a device that maxes at 16 texture units (been there done that).

[ZenCODE]

I stand to be corrected, but the atlas accesses the texture directly from GPU memory. These are created from a single load of the disk file.

For https://kivy.org/docs/api-kivy.atlas.html

    Atlas manages texture atlases: packing multiple textures into one.

What makes you say it goes to the hard drive?

[Horace Johnson]

Those sub frames you load with atlas...  You load them as 'source' when applying the image.  Source images in kivy will reload every time and this is what creates that 'thrashing' effect.  Notice how an atlas address a path...that's a clue.  When you're using a texture, there's is no physical path because the texture is stored in a cache (memory) and accessed from it.  Textures do not have to reload by path (from drive) when needed because they are already, ready to go in memory.

I have tested this effect over and over on an android device.  Animations using textures stored in memory makes way for a much higher frame rate...versus pulling images from path/drive every time they're needed.  I've worked with 2D game engines of the past that gave more control over what's loaded into memory and what's not, which makes me familiar with what's going on with kivy.

If I'm wrong, then something is terrible wrong under the kivy API hood because too much fps is still being lost if images from 'source' are indeed being kept in memory.  I was going to build out kivy's 3D side myself, only if I got past the 2D side.  So far, the 2D side is killing me.

[ZenCODE]

Alas, I fear you make too many assumptions. Look at the code.

https://github.com/kivy/kivy/blob/master/kivy/atlas.py

The only time files are loaded are on creation of the atlas. Although you access the parts of the image via file names, these names simply form dictionary keys to lookup the appropriate texture. There is no disc access, They are just names of files and that does not mean they are opened.

If you have performance issues, I suggest you try profiling the app to see where you CPU/GPU time is going, or look at Kivent for more optimized graphics performance? If I'm wrong, you'll see that in the profiling :-)

[Horace Johnson]

You do know kivy has cache APIs for storing an image in memory and using that image from memory, right?  If you're not storing in memory, using and dumping out of memory manually, you are relying on the OS to do so....which reminds me of  a game engine I used years ago but it did have manual control of loading and dumping from memory.

There's is nothing on kivy's atlas page which indicates the atlas is being kept in memory after a sub-image is loaded; which most likely mean textures loaded to the gpu will be forced out when not in use, in order to make room for new textures being used...which means previously used textures...  I'm sure you can see what's going on there (OS management).

I'm going to go ahead and use your assumption, that kivy is indeed storing the atlas in memory.  I'm almost afraid to find out what's going to happen when I stop using one atlas and refer to another  atlas.  Will the first atlas get dumped from memory or will atlas after atlas get loaded until the inevitable crash?

I guess I can only hope which every OS my app runs on, it will manage memory respectfully...given there is no manual loading into memory and dumping of an atlas.

Best regards

[Oon-Ee Ng]

Um, line 165 defines the Dict, line 223 sets it. And from then on the
textures are obtained from the dict. No file access at all. That's all
in memory (though not GPU memory).

> --
> You received this message because you are subscribed to the Google Groups
> "Kivy users support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kivy-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[ZenCODE]

Exactly. And it gets better. A new Atlas is created by loading via the CoreImage class, which uses a cache of loaded files.

https://kivy.org/docs/api-kivy.core.image.html

That means any number of indepenedly instantiated atlases (or even Images) load the file from disc only once. Then it's just dict lookup for the texture of the loaded image.

So, I think it's fair to say your fears are unfounded. Kivy has already considered these things. It's one of the reaons we love kivy :-)