Exploring possible issue with Sprite Load image from URL?

0 favourites
From the Asset Store
Minimal Sprite Font with Stroke for Pixel Art games.
  • It's not the execution time that is troublesome, it's all the memory allocation overhead of the whole process. Memory get allocated at a high pace and also quickly become flagged for collection, thus the regular garbage collection.

    First I thought using the BinaryData object would reduce the problem, but it seems to be plagued by the same excessive memory allocation...

  • Agreed on the memory allocation, this is where I started on the problem also, Major GC, blob creation seem to be the issue. However, I'm also exploring some more with coordination (or lack thereof between the rendering process and loading the Sprite image.) If the 'consumption' gets out of sync and delayed, perhaps blobs could be created without revoking. I'm adding in some check and variables, but have not yet seen improvement.

    I'll take a look at the BinaryData object too, but it sounds like you already did and it's not going to help.

    I really just want to have a reusable ping-pong buffer that is the size of the image data for the sprite that I can load into the Sprite (as long as that load does not create new blobs which must also be dealt with.) I may need to start exploring readpixels from the webgl context of the canvas that was rendered: WebGLRenderingContext.readPixels()

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I could not test the BinaryObject properly since it seems it can't load padded base64 (filed a bug report for that).

    However, 1 of your image in your example was not padded so I could test a bit. The JS Heap was still badly overused, although I did not test for any kind of difference in terms of lag.

  • Thanks for the help investigating this, that's too bad about the binary object. I have been working on the full project and trying some different ideas. However, then I just fall back to the test case that already has issues with just the one action, so I should probably just focus on that. I'm going to file a bug report and see if I can get some attention from Scirra also.

  • Filed a bug. In case anyone wants to follow the discussion there, see:


  • I am taking a new approach.

    I've created an ElementQuad helper plugin which is a Drawing plugin that replaces its initial texture with an Element from the document which can be set via an action. Right now I'm using the Spine render canvas as the Element to be used as a replacement texture. With this method, it looks there is not a large amount of new data/objects created to be GC'd later and the animations now run smoothly without a stutter. I will post the new template and plugin.

  • I've posted a project template with the plugin bundled.

    The new drawing plugin ElementQuad, takes an element as ID as an argument and each frame (Draw is called), it sets the image texture to the element (I am using the SpineCanvas which is the canvas I am using to render a Spine animation to.) It is just replacing the top MIP level, so you cannot scale the ElementQuad too much (or other MIP levels which do not contain the Sprite render will start blending in.) The ElementQuad image size works best if it's the same size as the Element (canvas.)

    So, the original issue in the thread is no longer blocking, this alternative approach also seems much more performant (with the caveat for the sizing limitations.)

    Here's a link to the template and plugin, please feel free to suggest improvements. It is still only a template and only one Spine object is currently supported.


  • It's not a bug, it's just the action is not designed to be used that way. See my comment on the bug.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)