I don't understand, why are we still using 'loader' to load resources even though we've already used 'starling'?

785597448 · May 22, 2026, 2:07am

I don’t understand, why are we still using ‘loader’ to load resources even though we’ve already used ‘starling’?

Why not use the ‘Starling’ resource manager?

Reliable Cancellation of `flash.display.Loader`

github.com/airsdk/Adobe-Runtime-Support

Reliable Cancellation of `flash.display.Loader`

opened 10:30AM - 21 May 26 UTC

2jfw

Feature Runtime: AIR

While creating an image list with Starling/Feathers displaying hundreds of large… (4K) images, I came across an issue with the `flash.display.Loader class`: it does not appear to be able to properly cancel in-flight load operations. Below is a summary of what I encountered: ## Summary `flash.display.Loader` provides no reliable way to cancel an in-progress load and free its decoded image data. This makes it impossible to build a responsive scrolling image list without memory leaks, particularly when using `ImageDecodingPolicy.ON_LOAD`. --- ## Background When building a scrolling list of images (e.g. hundreds of large or 4K images loaded from disk), the standard pattern is to reuse a `Loader` instance per item renderer and call `loader.load()` with a new URL each time the renderer is recycled. When the user scrolls fast, the previous load must be cancelled before starting the next one. The currently available cancellation API is `Loader.close()`. In theory this should abort the in-progress load and free all associated resources. In practice it does not. --- ## The Problem ### 1. `Loader.close()` does not free decoded image data when using `ImageDecodingPolicy.ON_LOAD` When a `Loader` is configured with `ImageDecodingPolicy.ON_LOAD`, the runtime begins decoding the image data into a `BitmapData` object as bytes arrive, before `COMPLETE` fires. Calling `close()` on such a loader does not free this partially or fully decoded `BitmapData`. The memory is held until `COMPLETE` eventually fires and `unload()` is called manually. This is acknowledged in the Feathers UI `ImageLoader` source code with the comment: > "when using `ImageDecodingPolicy.ON_LOAD`, calling `close()` seems to cause the image > data to get stuck in memory, unable to be garbage collected. To clean up the memory, > we need to wait for `Event.COMPLETE` to dispose the `BitmapData` and call `unload()`. > We can't do either of those things here." As a result, the only safe cleanup path with `ON_LOAD` is to attach orphan event listeners, wait for `COMPLETE` to fire, then manually call `bitmap.bitmapData.dispose()` and `loader.unload()`. This means the load is never truly cancelled — it runs to completion even when the result is no longer needed. In a scrolling list with hundreds of large images, this means every image the user scrolls past continues loading and decoding in the background, saturating I/O and memory until each one eventually completes and is disposed. The user experiences a long wait before the image they stopped on finally loads, because it is queued behind all the previous ones. ### 2. No way to know if a `Loader` is currently loading There is no `isLoading` property on `Loader` or `LoaderInfo`. Calling `close()` on a loader that is not currently loading throws a runtime error, requiring a try/catch around every `close()` call. This is poor API design that obscures intent and forces unnecessary exception handling. --- ## Impact This affects any application that: - Displays a scrollable list of images loaded from URLs or disk - Uses `ImageDecodingPolicy.ON_LOAD` for smooth scrolling performance - Needs to cancel in-progress loads when the user scrolls past an item renderer This is an extremely common use case — any photo browser, game screenshot viewer, media library, or product catalog built on AIR faces this problem. --- ## Requested Changes ### 1. `Loader.cancel()` method Add a new `cancel()` method to `flash.display.Loader` that: - Immediately stops all I/O and decoding - Frees all associated `BitmapData` memory synchronously - Does **not** dispatch `Event.COMPLETE`, `IOErrorEvent.IO_ERROR`, or any other event - Does **not** throw if the loader is not currently loading - Works correctly regardless of `ImageDecodingPolicy` This is distinct from the existing `close()` which attempts to stop I/O but does not free decoded data, and from `unload()` which only works after loading has completed. ### 2. `Loader.isLoading` property Add a boolean `isLoading` property to `flash.display.Loader` that returns `true` while a load is in progress and `false` otherwise. This eliminates the need for try/catch around `close()` calls and allows correct conditional logic. ### 3. Document `ImageDecodingPolicy.ON_LOAD` interaction with `close()` At minimum, if the above fixes are not feasible, document clearly in the `Loader` API reference that `close()` does not free decoded `BitmapData` when using `ImageDecodingPolicy.ON_LOAD`, and provide a recommended cleanup pattern. --- ## Workaround (Current State) The only currently viable workaround for a scrolling image list is to never cancel in-progress loads at all, and instead serialize loads so that only one load runs at a time per `Loader` instance. When a new source is requested while a load is in flight, the new URL is stored and the load is started only after the current one completes. This means fast scrolling through a list always loads the last image the user stopped on, skipping intermediate images. While acceptable for many use cases, it still means the user must wait for the previously-started load to finish before the new one begins — which can be several seconds for large images. A proper `cancel()` method would eliminate this wait entirely. --- ## References - Feathers UI `ImageLoader` source: https://github.com/feathersui/feathersui-starling/blob/master/source/feathers/controls/ImageLoader.as - Related Feathers issue (memory leak with large images): https://github.com/feathersui/feathersui-starling/issues/1454 - `ImageDecodingPolicy` API reference: https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/ImageDecodingPolicy.html - `Loader` API reference: https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Loader.html

Bink · May 22, 2026, 3:50am

In the context of Starling for ActionScript 3.0, the two AssetManager classes both tap into flash.display.Loader to perform their task.

The older starling.utils.AssetManager:

github.com/Gamua/Starling-Framework

starling/src/starling/utils/AssetManager.as

3806fed83


      
          //	Copyright Gamua GmbH. All Rights Reserved.
          //
          //	This program is free software. You can redistribute and/or modify it
          //	in accordance with the terms of the accompanying license agreement.
          //
          // =================================================================================================
          
          package starling.utils
          {
              import flash.display.Bitmap;
              import flash.display.Loader;
              import flash.display.LoaderInfo;
              import flash.events.HTTPStatusEvent;
              import flash.events.IOErrorEvent;
              import flash.events.ProgressEvent;
              import flash.events.SecurityErrorEvent;
              import flash.media.Sound;
              import flash.media.SoundChannel;
              import flash.media.SoundTransform;
              import flash.net.FileReference;
              import flash.net.URLLoader;

github.com/Gamua/Starling-Framework

starling/src/starling/utils/AssetManager.as

3806fed83


      
          var loader:Loader = new Loader();
          loaderContext.imageDecodingPolicy = ImageDecodingPolicy.ON_LOAD;

The newer starling.assets.AssetManager uses the starling.assets.BitmapTextureFactory, which uses it:

github.com/Gamua/Starling-Framework

starling/src/starling/assets/BitmapTextureFactory.as

master


      
          package starling.assets
          {
              import flash.display.Bitmap;
              import flash.display.BitmapData;
              import flash.display.Loader;
              import flash.display.LoaderInfo;
              import flash.events.Event;
              import flash.events.IOErrorEvent;
              import flash.system.ImageDecodingPolicy;
              import flash.system.LoaderContext;
              import flash.utils.ByteArray;
          
              import starling.textures.Texture;
              import starling.textures.TextureOptions;
              import starling.utils.ByteArrayUtil;

github.com/Gamua/Starling-Framework

starling/src/starling/assets/BitmapTextureFactory.as

master


      
           *  @param data        A ByteArray that contains image data
           *                     (like the contents of a PNG or JPG file).
           *  @param onComplete  Called with the BitmapData when successful.
           *                     <pre>function(bitmapData:BitmapData):void;</pre>
           *  @param onError     To be called when creation fails for some reason.
           *                     <pre>function(error:String):void</pre>
           */
          protected function createBitmapDataFromByteArray(data:ByteArray,
                                                           onComplete:Function, onError:Function):void
          {
              var loader:Loader = new Loader();
              var loaderInfo:LoaderInfo = loader.contentLoaderInfo;
              loaderInfo.addEventListener(IOErrorEvent.IO_ERROR, onIoError);
              loaderInfo.addEventListener(Event.COMPLETE, onLoaderComplete);
              var loaderContext:LoaderContext = new LoaderContext();
              loaderContext.imageDecodingPolicy = ImageDecodingPolicy.ON_LOAD;
              loader.loadBytes(data, loaderContext);
          
              function onIoError(event:IOErrorEvent):void
              {
                  cleanup();

785597448 · May 22, 2026, 6:00am

@Bink

Oh, I see. Sorry, I rarely check the source code of “Starling”. Thank you for letting me know

785597448 · May 22, 2026, 11:55am

@Bink Will openfl starling have the same problem as above? Thank you

joshtynjala · May 22, 2026, 4:48pm

OpenFL does not appear to have an implementation of ImageDecodingPolicy.ON_LOAD yet, so it would not have the same issue.

I don't understand, why are we still using 'loader' to load resources even though we've already used 'starling'?

Reliable Cancellation of flash.display.Loader

Reliable Cancellation of `flash.display.Loader`