Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[spine-ts] Spine-player continuously adding memory on looping animation in iphone Safari #2422

Open
Futekov3216 opened this issue Nov 20, 2023 · 5 comments
Open

[spine-ts] Spine-player continuously adding memory on looping animation in iphone Safari #2422

Futekov3216 opened this issue Nov 20, 2023 · 5 comments
Assignees
@badlogic

Comments

@Futekov3216
Copy link

I have tested with iphone 12 mini - iOS 16.6.1

spine-ts/spine-player.
https://github.com/EsotericSoftware/spine-runtimes/tree/4.1/spine-ts/spine-player

The issue is that when you leave the spine-player running a looping animation it continuously adding memory and disposing the player the memory is not cleared. I am providing the information from the developer tools

legend-spine

As you can see after the disposing the memory persists the value that was accumulated in the period and it is not cleared
@badlogic
Copy link
Collaborator

This can not be reproduced on the desktop with spine-player/example/index.html (Chrome 119.0.6045.159, Firefox 121.0b3, Safari 17.1 (19616.2.9.11.7))

I've especially looked at Safari, and it shows no memory leaks. It keeps hovering around the same peak value.

Screenshot 2023-11-26 at 13 29 29

I currently don't have a physical iOS device on hand, but should have on next week. I'll test there as well. But given that both Safari and Safari mobile share pretty much the same WebKit implementation, I doubt it will be any different.

Disposing a player does what it's supposed to do: remove all references to WebGL resources. Whether the browser engine actually disposes them is out of our hands. What you see here is likely WebKit simply holding on to the WebGL resources until the memory pressure gets too big.

I'll update this issue once I have an iPhone to test with.

@badlogic
Copy link
Collaborator

Oh, and if you have your own test harness for this, please share it. It's impossible to debug this without being able to reproduce it on my end.

@Futekov3216
Copy link
Author

I do confirm that this only happens on Iphones. As mentioned i am testing with your example provided on this runtime

https://github.com/EsotericSoftware/spine-runtimes/tree/4.1/spine-ts/spine-player

The only difference is that i am using webpack for running it on the local network.

@badlogic
Copy link
Collaborator

Well, your screenshot says mount/unmount, so webpack isn't the only difference. You are likely using something like Vue/React/whatever. And my guess is, that your component gets remounted all the time until it's unmounted. That's the only thing I can think off for why this is happening on your end.

So please, also provide your test harness.

@Futekov3216
Copy link
Author

Its just a professional distortion, i am testing with your dispose.html template that looks like this

`<!doctype html>

<script src="../iife/spine-player.js"></script> <style> body { background: gray; margin: 0px; } </style>
Dispose Get
<script> var player = null; 
document.getElementById("dispose").addEventListener("click", event => {
	console.log("Disposing player.");
	player.dispose();
	player = null
});

document.getElementById("get").addEventListener("click", event => {
	if(player === null)
	player = createPlayer();
});


function createPlayer() {
	return new spine.SpinePlayer("container", {
		skelUrl: "../assets/spineboy-pro.skel",
		atlasUrl: "../assets/spineboy-pma.atlas",
		animation: "run",
		premultipliedAlpha: true,
		backgroundColor: "#cccccc",
		viewport: {
			debugRender: true,
		},
		showControls: true
	});
}
</script> `

@badlogic badlogic self-assigned this May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@badlogic badlogic

Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@badlogic @Futekov3216