When hover over a function show the graph

[GhostNr1]

Description

When we hover a function it will just show some data that is't that usefull. It would be more usefull to have the graph from the function show in the hover window. This would make it much faster to go thru the graph not needing to jump into every function. That will make it easyer to do many small function without needing to hope in and out to see what is going on.

Implementation ideas

When you hover over a function the graph in that function should be visible

[Naros]

To be clear, are you referring to a similar hover-over rendered image like the main viewport tabs work, where if you hover over the non-active tab, you get a rendered image of the underlying scene?

So in the case of Orchestrator, if you have the "EventGraph" and a user-defined function tab open in the Orchestrator main panel, if the "EventGraph" is active, hovering over the function tab would show a popup of the rendered graph in a small popup rendered image?

[GhostNr1]

Well yes and no,

Here I have a function that is called Set position, if I hover over the mouse I would like to get like a minimap that show that kind of function without needing to enter it. So the minimap should show this

[Naros]

Thumbnail rendering is more involved than it may seem.

We can either try to be slick and only regenerate the thumbnails as necessary, or we can be inefficient and generate the thumbnail on each hover. I'd prefer the former, but presently GDExtension does not expose access to the set_edited and the is_edited methods on Godot::Object, so this would require we try and roll our own, which seems overkill.

The complicated part of this is the interaction needed between GraphEdit and SubViewport. To render these thumbnails, we need to have a SubViewport that acts as an off-screen renderer, where we add each function graph as a child, it is rendered, and we capture that rendered texture as an image for tooltips. GraphEdit is designed differently from other UI widgets, and it requires a number of frames before it's actually fully rendered. So we need to have a reliable way to know when GraphEdit not only is added to the scene, but that it's positioned so we get the expected output. There is the scroll_offset_changed signal, but using this involves effectively waiting for this to fire twice before capturing the image.

For now, I'm going to delay adding this just due to its complexity and perhaps when my upstream PR to add set_edited and the is_edited methods to GDExtension for all godot::Object types is merged, this may be ever so slightly easier.

[GhostNr1]

I think this is a more of a "nice to have" feature then something important. If it's complicated as you say I also think it's much better to way until it gets easier to implement rather then do this just because.

Much better to put the time and effort on issues that give more value at the moment, but keep this open until it make sense to do it.