Skip to content

Delay destruction of graphics by a small amount of time #3565

Open

Description

@Geokureli

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

  1. 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;
}
  1. 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

Activity

  1. ACrazyTown commented on Mar 9, 2026

    @ACrazyTown
    Contributor

    Haven't read through the entire thing yet but I think FlxGraphicResource could very well be a FlxTexture from the aforementioned issue. There may be different `FlxGraphic' that share the underlying GPU texture

  2. ACrazyTown commented on Mar 9, 2026

    @ACrazyTown
    Contributor

    I like approach number 2, having more control and being able to explicitly change behavior seems nice.

    Also, isn't this similar to #3411?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions