[godot] SpineSprite disappears when window is resized

[badlogic]

Confirmed on Windows.

[Dssdiego]

This sometimes will cause flickering for low end PC's as well (when launching a game that contains multiple sprites in the same screen)

[Aeister]

Any news on the issue?

[tarragonfly]

This is a major reason why we can't use Spine for our next project. Hope this gets addressed sometime in the future.

[DASilverStraw]

I was able to stop SpineSprite from disappearing when the window is resizing by using this GDScript combination.

func _ready() -> void:
	self.get_tree().connect( 'screen_resized', self, '_on_scene_tree_screen_resized' )

func _on_scene_tree_screen_resized() -> void:
	VisualServer.force_draw()
	VisualServer.render_loop_enabled = false
	yield( self.get_tree(), 'idle_frame' )
	VisualServer.render_loop_enabled = true

[badlogic]

Huh, could you explain how this works? I've tried to fix this a couple of times now, and still don't understand why it happens in the first place.

…

On Fri, Feb 3, 2023, 16:00 DASilverStraw ***@***.***> wrote: I was able to stop SpineSprite from disappearing when the window is resizing by using this GDScript combination. func _ready() -> void: self.get_tree().connect( 'screen_resized', self, '_on_scene_tree_screen_resized' ) func _on_scene_tree_screen_resized() -> void: VisualServer.force_draw() VisualServer.render_loop_enabled = false yield( self.get_tree(), 'idle_frame' ) VisualServer.render_loop_enabled = true — Reply to this email directly, view it on GitHub <#2119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5QBHRLCBXTBPSIET4GH3WVUMRJANCNFSM537YKQ7Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[badlogic]

Right, I understand what the code itself does. But I do not understand why it is at all necessary. Godot's own `Sprite` for example does not suffer this deficiency. However, I went through its code and the code of the classes it subclasses and do not find any such resizing related "hacks". I can't generally apply this in the Spine Godot plugin either. I guess I'll keep digging and asking on the Godot chat how to resolve this.

…

On Fri, Feb 3, 2023 at 5:23 PM DASilverStraw ***@***.***> wrote: This GDScript was arrived from research and testing different code combinations. Scene Tree class has a 'screen_resized' signal. Documentation reads: emitted when the screen resolution (fullscreen) or window size (windowed) changes. I tried use 'size_changed' signal from Viewport class but there was black fickering when the window resizes. By turning off the render loop during screen resizing, the current frame image doesn't get erased. It alone has issues of black unrendered areas and image freezing during screen resize. Yield is a co-routine for pausing the function until next frame when render loop resumes. Force draw is called every time the Scene Tree receives the 'screen_resized' signal. Force draw takes a swap buffer boolean argument (default true). More buffers help with the amount of force draws. I tried using multiple force draws in the function but that resulted in rapid flickering of the image. I combined both force drawing and pausing the render loop until the next frame and it seem to work. Screen resizing emit multiple signals. As long as the signals keep being emitted, the render loop is paused and force draws take over. If the render loop remain active while force draws are invoked, the render loop erases the forcibly drawn image. I hope this helps. — Reply to this email directly, view it on GitHub <#2119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5QBES52IORG7UQ3Q7TW3WVUWIHANCNFSM537YKQ7Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[DASilverStraw]

The rendering of the debug options don't seem to be affected when resizing the window.
Sorry I haven't really looked into the cause of the issue.

[badlogic]

Spend most of the day figuring this out and finally fixed it.

SpineSprite would instantiate one MeshInstance2D per skeleton slot. Every frame, it would clear the meshes' canvas item, then set the new triangles via VisualServer::canvas_add_triangle_array(). That's actually "illegal" in the Godot world it seems. The method must be called by the MeshInstance2D node itself in the handler code for the NOTIFICATION_DRAW event.

I've fixed this by creating a custom Node2D called SpineMesh2D. It stores the triangles, indices, and material for a single slot in a skeleton. The SpineSprite updates those triangles, indices, and materials of every SpineMesh2D when it processes an update. The SpineMesh2D instances then are responsible for actually submitting the triangles to the VisualServer.

That fixes this issue and likely fixes other issues yet unseen/unnoticed related to "illegally" modifying the canvas item of child nodes outside their respective NOTIFICATION_DRAW handler code.