Helping visualizers respond to canvas resizing

[Vectornaut]

Typically, p5 sketch designers either fix the canvas dimensions or make sure that the draw method works correctly when the canvas dimensions change from frame to frame. However, we've currently decided that we don't want to allow fixed-dimension visualizers, and we want to give visualizer designers a simplified way of reacting to canvas dimension changes.

While you're working on helping visualizers to react to parameter changes in real time, it could be useful for you to think of dimension changes as a type of parameter change. They're not entirely the same, since dimension changes can happen many times per second while the browser window is being resized, while the kinds of parameter changes we have right now can only happen every second or two. However, being able to handle dimension changes and parameter changes in the same way could be make things easier for some visualizer designers.

[maxd0328]

These are good things for us to keep in mind, and we'll make sure that the visualizer API is inherently reactive to changes in dimension.

This also brings into question the idea of introducing a new (more standardized) coordinate system for visualizers, which is independent of the exact dimensions of the images (not reliant on pixel coordinates). This would likely involve creating a layer in between visualizers and p5 to do this calculation, but it is something that should be decided on now before everything is in place. What do you think?

[katestange]

The writers of visualizers often want pixel-level control, so they want to work with the pixel dimensions of the canvas. If I understand correctly, your suggestions would remove that? I'm concerned that the "resampling" effect would degrade quality, also.

[gwhitney]

And in particular, some visualizers may want to draw their "thumbnails" a bit differently than their "fullscreen" visualizations. So visualizers will need to know their absolute canvas dimensions anyway, generally speaking.

[maxd0328]

Right, I understand your concerns. I suppose it's also the case that anything is possible given the visualizer API is general enough. As long as it stays this way, there could even be support in the future for GPU-accelerated visualizers. For now I've left the structure of the visualizer interface more or less the same, with the P5 visualizer sitting on top of it.