Resource limit for this resource type exceeded.

bas

Hi there,

Trying to move some bigger stuff around, so I made an Image and applied a Texture from a 400x218 bitmap ( http://www.openclipart.org/image/400px/svg_to_png/rg1024_cartoon_whale.png ). Flash throws the following exception:

Error: Error #3691: Resource limit for this resource type exceeded.
at flash.display3D::Context3D/createTexture()
at starling.textures::Texture$/fromBitmapData()[C:\Users\bas\Dropbox\Development\StarlingTest\lib\starling\textures\Texture.as:108]
at Game()[C:\Users\bas\Dropbox\Development\StarlingTest\src\Game.as:47]
at starling.core::Starling/initializeRoot()[C:\Users\bas\Dropbox\Development\StarlingTest\lib\starling\core\Starling.as:225]
at starling.core::Starling/onContextCreated()[C:\Users\bas\Dropbox\Development\StarlingTest\lib\starling\core\Starling.as:320]

This looks to be related to the size of the bitmap I used. If so, what is the max size I can use for a Texture? I thought I read somewhere it was 2048x2048?

Thanks!

bas

Oh duh... My own fault. One hour later, I noticed the Texture creation was inside a big fat loop. Obviously blowing everything up.

Did learn though that you can reuse textures without consuming more memory. Like reusing BitmapData.

Fallsburg

I'm going to hijack this, since I figure that two threads with the same topic is probably not the best idea.

I got the "[Fault] exception, information=Error: Error #3691: Resource limit for this resource type exceeded." error in my code despite doing everything right (or so I think). My code is based on the Flixel framework which I have hacked so that it uses Starling for the rendering. Upon the creation of my game, I instantiate a whole bunch of sprites, textures, movieclips, etc. This is fine, but when I switch to a new level, I dispose of everything that I previously created and do it all over again. After going to 3 or so levels, I would run into the aforementioned error.
I searched high and low and for the cause of the error and took the following actions
1) I created a dictionary of Textures, so that any time I would do Texture.fromBitmapData, I just looked to see if it was in the texture dictionary. If it was, I returned it, if not I created it. Didn't fix the problem
2) I made sure to dispose of EVERYTHING. I disposed of the root Sprite (starling, of course) that contained everything. I also went through and disposed of every single other Sprite, Image, MovieClip, RenderTexture that I created just to be sure (knowing that the disposal of the root Sprite should have disposed of everything else). I know for a fact that I disposed of every single display object that I created, as I kept reference counts to verify this. Didn't fix the problem
3) I hacked SubTexture to dispose of its parent Texture. This fixed the problem.

Now, maybe I am doing something horribly wrong by making SubTexture dispose of its parent Texture. Maybe I'm doing something horribly wrong such that this is the only thing that I was able to find that fixed the problem. But I'm unable to see where I went wrong. The disposal of the parent Texture makes sure that all Textures are disposed of when I want them to be disposed (re: Reference counting), and I haven't noticed any adverse effects.

The possible conclusions are:
1) I'm horribly misunderstanding the disposal system in Starling, and I was/am doing something extremely wrong. I don't like this conclusion, as I feel that I have been thorough in my search.
2) There is a bug in Starling. I feel like my solution only fixed the symptom of the bug, not the cause. My guess is that for some reason Starling is creating copies of parent textures for SubTextures, hence their need for disposal.
3) Some third option.

Any insight would be helpful. Thanks!

Daniel

Hi!

Have you tried to just dispose the parent texture?

Because when you dispose a display object, its vertex and index buffers will be disposed, but not its texture (if it's an image). That's because that texture might be used by other objects as well -- and even if it isn't, you might be keeping it in a collection (as you do), and there's no way for Starling to know about that. Thus, Starling can't dispose it.

When it comes to freeing resources, a reference counting system (like in Objective-C) actually makes it easier to be sure that everything is disposed than having a GC like that of Flash. In developing Starling, I was reminded of that very often! 😉

Daniel

ColinNorthway

I ran into exactly the same problem as Fallsburg.

Sometimes Texture.fromBitmapData returns a SubTexture and sometimes it returns a ConcreteTexture (depending on if the size of the bitmap is a power of 2 or not).

But then SubTexture.dispose doesn't actually remove anything from texture memory because it's intended to be a view into a larger texture.

This way if you .fromBitmapData a bunch of textures you then have to use reflection to free them.

texture.dispose();
if ( texture is SubTexture ) {
  (texture as SubTexture).parent.dispose();
}

Daniel

Thanks for sharing your workaround, Colin!
I will make that easier in the next version. When you use "fromBitmapData" and it returns a subtexture, I will mark that subtexture as "owning" its concrete texture, allowing it to dispose it when the subtexture is disposed.

regan

WOW, thanks a lot Colin!! I have been struggling with this issue for a quite long time
http://forum.starling-framework.org/topic/textfieldtextbounds-is-leaking#post-1118

Lately I found, that EVERY usage (basicaly any text assignment, not just the two cases I mentioned above) of starling TextField leaks one texture (to the maximum limit of 4096). Inserting your lines of code in the dispose method of starling TextField worked like a charm! No #3691 error anymore!!! Yahoooo 😃

Daniel

The workaround should now not be necessary any longer -- the latest development version of Starling disposes textures the way I described it my previous post.

oopstoons

What is the limit? Unfortunately, the game I am working on has a ton of assets with the potential of them all being used at once. I have a working version of the game using bitmapdata. It is able to support many of these assets at once, but not with good performance. But I wanted to see what kind of performance gain I could get with Starling, but I'm unable to create enough textures to test big levels.

What kinds of limits are there? Are those imposed by Starling or Flash? Is that configurable? Is that dependent on AS3 version? What can I do to pack in more art assets (other than great texture packers)?

Are there also limits on the data or are there only image restrictions?

Thanks.

Jeff

The original topic issue was running out of GPU texture memory so I assume your question is regarding limit of GPU textures?

It depends upon which devices you need to run on.

The docs for Context3D (the Stage3D class that is the backbone for Starling):
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display3D/Context3D.html

has a line:

350 MB is the absolute limit for textures, including the texture memory required for mipmaps. However, many devices do not support this much texture memory. For maximum compatibility, limit texture memory use to 128 MB, or less.

So if you are developing an app for mobile there will be a range of device limits (even across iOS).

If you can make use of ATF textures you can reduce the per-image texture memory size, at the expense of quality, if texture memory use is at a premium.

wrench

I found that doing things as simple as not clearing up an listener on a timer object within one of my Starling displayobjects was more than enough to bring up a #3691 error after running the AIR app for an hour or so (I'm creating a dashboard for a telly).

So, remember to clear up ALL event listeners or declare them weakly.

wrench

Upon slightly more investigation, I'm finding calling removeChildren(0, -1, true) when destroying my displayobject instances also very useful when it comes to keeping the memory footprint of the app stable.

wrench

Ok, apologies to anyone who's listening to this thread - after removing my calls to removeChildren(0, -1, true) I noticed that although the GPU memory was still stable, the Flash memory was climbing steadily. Adding that one line back into my destroy() call fixes that issue. Guessing the extra stuff that gets called in removeChildAt (which is the call removeChildren loops over internally) helps to remove all references to the objects being removed from stage.

UPDATE: It turns out that the issue I was experiencing was actually related to Starling-Extension-Graphics framework I was using to get the Flash Shape drawing functionality into my app. This commit was made on the 9th of March, which I hadn't bothered to download - https://github.com/unwrong/Starling-Extension-Graphics/commit/f64b975f8710c75b034296f2fe474ff7278ffb56
So you can safely ignore the red herrings above 😉

bibishou

texture.dispose();
if ( texture is SubTexture ) {
(texture as SubTexture).parent.dispose();
}

Does it need to do in now version's Starling?

I meet "[Fault] exception, information=Error: Error #3691: Resource limit for this resource type exceeded."

I use AssetManager to load and dispose.

starlingnoob

I am not sure about the texture.dispose and the work around. But I did wind up here because I was getting the error and I was freaking out because I had just added a good amount of assets to my game. The fix I came across was.. I had no cleared out my bin-debug assets folder since day one of this project and it had accumulated to upwards of 30 mb's of images. So I deleted the folder and then ran it from FB and viola! Fired up right away! No more errors! I guess I was not keeping the bin-debug folder clean! Maybe this will help someone else scratching their head with this error!

DanielKotzer

How many textures can I use before I hit the limit and get the error message: Resource limit for this resource type exceeded?

and when do I use texture.dispose();?
during rendering time when I go through each object and render it, I should create the texture for the object and render it and then dispose it? isn't that slowing down the rendering?

Bink

DanielKotzer How many textures can I use before I hit the limit and get the error message: Resource limit for this resource type exceeded?

It's not so much a question of how many textures, it's how much texture memory can you consume. The number of textures that represents will vary depending on a number of things.

The types of textures. ATF textures consume less memory and depending on how they're compressed, PVRTC, ETC1, ETC2, DXT, with or without JXR compression, with or without alpha, they can take up less memory still.
Things like TexturePacker can pack image assets into spritesheets, cropping each asset in the spritesheet based on transparency. In code though, the asset still behaves as though it's un-cropped and will position as you intended. TexturePacker also provides the means and options to export to ATF as well.
What version of AIR SDK you're using. Prior to release 29, GPU memory was limited to 512MB. AIR 29 introduced two new Context3DProfiles that increased the GPU memory limit to 2048MB. These profiles are "Standard_Extended" and "Enhanced" and the additional memory is only supported in 64bit builds. It's worth noting that limit doesn't equate to textures memory limit, as there are some other things going on in the GPU as well as textures.

Most of my work targets high-end desktop systems so I won't speak to mobile. The most textures I've ever included in a live project, was about 60 4096x4096 ATF textures using the above techniques. I don't believe I'd hit a limit yet.

Under 32bit, the most I'd ever been able to achieve was around the mid 20's.

DanielKotzer

And disposing the texture after each render (30 times a second) is not practical right? if so, then the previous comments on this tread that was suggesting I should dispose the texture, when am I supposed to do it? I use it for the render.

Bink

DanielKotzer the previous comments on this tread that was suggesting I should dispose the texture, when am I supposed to do it?

This really depends. As you suggest, disposing of it 30 times a second in most cases will not be practical. There have been situations where I've needed to do this though. I received image data over a network that needed to be displayed like video. The image data was assembled, uploaded to the GPU as a Texture, rendered, then on the next frame disposed and the process repeated. This was a pretty specific case though and not likely applicable to the majority of apps.

If it's a game, you might load textures that relate to a specific level, as the level loads. When the level ends, you dispose of those textures. In the same game, you may unload textures specific to the main menu when the game starts, then reload them if the game ends.

When it's done depends on the game/app. If you provide an idea of flow, someone may be able to offer some suggestions.

DanielKotzer

This was very helpful thank you.