search

numberscope / frontscope

Numberscope's front end and user interface: responsible for specifying sequences and defining and displaying visualizers
MIT License
7 stars 15 forks source link

standardized zoom/pan etc. #385

Open katestange opened 3 months ago

katestange commented 3 months ago

It might make sense to standardize zoom, pan and other controls that are commonly used across many visualizers. This might take the form of documentation suggestions to visualizer writers, or some functionality that is available to visualizer writers, to encourage the use of the same keyboard/mouse controls for such things in different visualizers.

gwhitney commented 2 months ago

I mean, if we switch primarily to the SVG version of p5, the base class should be able to implement pan and zoom with no action on the part of the visualizer writer (although we might want to provide hooks in case a specific visualizer wants to catch that action).

gwhitney commented 1 month ago

Actually, I made a serendipitous discovery in the course of working on #420 and #225: I wanted hatching in the FactorHistogram visualizer, and the package I could find to do that was p5.brush, and that needed to use the WebGL option for p5. So I made a way to turn that on, and it turns out that when rendering with WebGL in standard p5, the renderer keeps a complete model of everything that has been drawn, easily allowing zoom and pan with no additional effort on the part of the visualizer writer. You can now see this in action in #420: pull that PR, make sure to do npm install, and then try any FactorHistogram visualization. I have enabled p5's default interaction gestures, so you should be able to zoom in and out with the mousewheel, and pan around with right-mouse-click-dragging on the background, and you can even try ordinary left-click dragging as well to see the crazy thing that does. We could of course change what gesture controls what and likely turn off some of the gestures, but it seems quite plausible to me to contemplate making all visualizers WebGL-based and just turn on some of these standard features in lieu of visualizers needing to do anything special themselves for pan and zoom. So @katestange / @Vectornaut please give it a whirl and let me know what you think.

It's possible that this approach could even help with responding to window resize. One caveat is that a resize often involves a change in the aspect ratio of the image, and it's not clear there's any simple/automatic way to transform existing drawings to a different aspect ratio. But it could well help in many cases, for example in those cases where a resized window simply means that a different portion of what's been drawn is visible -- stuff that's currently off screen is still there and will show up when the view changes to include it.

For example, FactorFence could be changed to draw each bar once (except for color changes), rather than re-draw all the bars on each frame, and just keep adding bars that are just off the edge of the screen so that you keep the current impression that the fence goes on forever. I think that approach could handle everything FactorFence does now (with noticeably less code), except for the vertical stretch -- I am not aware of a way to stretch an existing polygon in WebGL in just one direction.

katestange commented 1 month ago

Wow! Well it works on histogram but the 3d aspects (left-click) are distracting not helpful on that visualizer (clearly). The pan is ok (it has a little elasticity I see). The zoom is nice in that it "just works" but it doesn't zoom to your mouse position, it zooms to center. So I'm not sure this is close to ready to drop-in replace the work in FactorFence... But it seems like turning these on by default unless the visualizer wants to override them would be a great feature. For many visualizers this would just be a nice addition.

katestange commented 1 month ago

For example, FactorFence could be changed to draw each bar once (except for color changes), rather than re-draw all the bars on each frame, and just keep adding bars that are just off the edge of the screen so that you keep the current impression that the fence goes on forever. I think that approach could handle everything FactorFence does now (with noticeably less code), except for the vertical stretch -- I am not aware of a way to stretch an existing polygon in WebGL in just one direction.

This is intriguing, especially if it means faster processing when you zoom out and it gets laggy because of all the gradients!

gwhitney commented 1 month ago

But it seems like turning these on by default unless the visualizer wants to override them would be a great feature. For many visualizers this would just be a nice addition.

Right, we can by default turn off the 3D rotation and move the pan to left drag, and just change most visualizers to work with webgl. As a later step, we can make it zoom to mouse position by default. And we can investigate if this eases the resize situation for some visualizers. But we will need to see how webgl does with gradients before we could change FactorFence to use webgl. As you say, maybe it will be a real boon.