Windowing system

[matthewturk]

It would be nice if we had an easier interface for a windowing system, whether that's built with imgui or not. This would make it much easier to do subset rendering (i.e., not rendering the volume that is covered by imgui!) and things like multiple views.

[matthewturk]

We have the ability already to do display_bounds. For instance:

import yt
import yt_idv

ds = yt.load_sample("IsolatedGalaxy")

rc = yt_idv.render_context(height=800, width=800, gui=True)
sg = rc.add_scene(ds, "density", no_ghost=True)
sg.components[0].display_bounds = (0.0, 0.5, 0.0, 0.5)
rc.run()

nicely puts our main display in the lower left. But, this doesn't have the ability to change the size, and it also still sends events to all the windows.

What I'd like to propose:

• draw lines on all the borders
• implement dragging on the lines/borders (maybe use imgui for this?)
• set it up so that one display is designated as "active" and all events go there.

I think it might be out of spec to do much of anything with adding displays dynamically... But we can think about that.

[matthewturk]

One thing I'm thinking about here is that we generally have a single camera per scene object. So the notion of an active view is a little different because of that. We may want to separate out the camera into multiple objects, each of which is tied to a specific view of the scene.

[matthewturk]

Alright, here's what I think we should do. It might be too much, though.

1. Refactor so that inside the Scene, which becomes the mechanism by which access to SceneData elements is handled, there are multiple View objects. These contain Components and Annotations and a Camera.
2. Default to having one single view that owns everything that is displayed, with display bounds of 0 .. 1. This would mean moving the display bounds to the view, and delegating access to that. We'd likely have to pass a reference to the view into the render method as well.
3. Have views be in the pyimgui interface, and select between them for which can receive events.
4. Move event handling primarily to the View object, with fallback in the Scene.

I need to think more about this, but this seems like how we'd need to go.

[matthewturk]

At the risk of commenting too quickly, it looks like upon closer inspection we could simply rename the bulk of what constitutes the SceneGraph into a SceneView.