I thought of this a while back but never wrote it down; it would be nice if decrementing the useCount of a FlxGraphic didn't immediately destroy it. graphic.persists prevents this, but I think there are obvious cases where a slight deferral is preferred. Examples:
I imagine that in most cases we could simply wait 1 frame.
Possible Solutions
- in FlxGraphic.checkUseCount we could do:
function checkUseCountDeferred()
{
if (canDestroyUnused())
{
var frameCount = 0;
FlxG.signals.postUpdate.add(function onUpdate()
{
if (++frameCount > 2)
{
FlxG.signals.postUpdate.remove(onUpdate);
checkUseCount();
}
});
}
}
function checkUseCount()
{
if (canDestroyUnused())
FlxG.bitmap.remove(this);
}
function canDestroyUnused()
{
return useCount <= 0 && destroyOnNoUse && !persist;
}
- Deprecate destroyOnNoUse and add:
enum FlxGraphicAutoDestroy
{
NEVER;
STATE_SWITCH;
NO_USES;
NO_USES_DEFERRED(numFrames:Int);
// Or perhaps just: NO_USES(?numFrames:Int), but I hate Null<Int> here
}
There may be other types of deferral in the future so perhaps FlxGraphicAutoDestroy.NO_USES(?deferral:FlxDestroyDeferral) with deferral options IMMEDIATE (or null) or FRAMES(numFrames:Int)
Impact on existing code
If we changed the default behavior of FlxGraphics to defer destroy, games that edited bitmaps, and expected immediate destruction on no use, will have their edits unexpectedly maintained. No impacts if the default behavior remains "immediate".
FlxGraphicsResource
Very tangential, and I only have a rough idea, but It might also be a good idea to further separate FlxGraphic from the cached resource. Where FlxGraphics have a reference to a globally managed resource or a unique, locally managed copy of it. This might also help with #3540
Global Default
As outlined in #3411: a way to set the default auto destroy via FlxG.assets.defaultCachingMode or FlxG.assets.defaultAutoDestroy
I thought of this a while back but never wrote it down; it would be nice if decrementing the useCount of a FlxGraphic didn't immediately destroy it.
graphic.persistsprevents this, but I think there are obvious cases where a slight deferral is preferred. Examples:I imagine that in most cases we could simply wait 1 frame.
Possible Solutions
There may be other types of deferral in the future so perhaps
FlxGraphicAutoDestroy.NO_USES(?deferral:FlxDestroyDeferral)with deferral options IMMEDIATE (or null) or FRAMES(numFrames:Int)Impact on existing code
If we changed the default behavior of FlxGraphics to defer destroy, games that edited bitmaps, and expected immediate destruction on no use, will have their edits unexpectedly maintained. No impacts if the default behavior remains "immediate".
FlxGraphicsResource
Very tangential, and I only have a rough idea, but It might also be a good idea to further separate FlxGraphic from the cached resource. Where FlxGraphics have a reference to a globally managed resource or a
unique, locally managed copy of it. This might also help with #3540Global Default
As outlined in #3411: a way to set the default auto destroy via
FlxG.assets.defaultCachingModeorFlxG.assets.defaultAutoDestroy