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

Adapt Visualizers to non-square/resizing canvases #282

Open gwhitney opened 5 months ago

gwhitney commented 5 months ago

According to @katestange in #277, the Histogram visualizer has trouble with its x-axis labels in non-square/resizing canvases.

The Grid visualizer assumes the canvas is square, and part of the display is lost if not. Should it just only work on the largest square that can fit, or is there any use for laying out numbers in a rectangular grid?

ModFill uses non-square blocks when the canvas is non-square. This may make the display a little bit harder to interpret; it's not clear it has any advantage over just always using a centered square of square blocks.

Glyph visualizer works OK, but its display is at one end of the screen and there can be signficant blank space. It should either be centered or enhanced to allow non-square rectangles of glyphs.

One potential approach for some of these cases would be to create a SquareVisualizer class that derives from P5Visualizer but creates (the largest possible) square canvas, centered in the provided div. Then visualizers that only want to work on a square could just derive from that. See also #279 and #281.

Vectornaut commented 5 months ago

Mod Fill also responds weirdly during canvas resizing. This is because it builds the visualization progressively, considering one new element per frame.

Do either of you know whether the Mod Fill author chose progressive rendering for aesthetic reasons? If the progressive rendering is just for computational convenience, we could probably fix the resizing issue easily by doing all the rendering in one frame. On the other hand, if the progressive rendering was an aesthetic choice, we should think about how to show the animation in a way that can be resized on the fly (and maybe can be restarted without hitting "back" and re-creating the visualizer).

katestange commented 5 months ago

As a step toward "hot modification" maybe all visualizers should be required to respond to a request to "renew", which could be a keystroke they all have to respect, or something like that, and which is also triggered upon resizing.

gwhitney commented 5 months ago

Do either of you know whether the Mod Fill author chose progressive rendering for aesthetic reasons?

Only Kate was around when it was merged in. But I've always assumed the time element was a way to get entry index information into the visualization.

maybe all visualizers should be required to respond to a request to "renew", which could be a keystroke they all have to respect,

A similar point has come up in the discussion in #293. It seems very likely that the VisualizerInterface will at some point soon need to have such a "renew()" call, meaning restart the drawing from the top (first index, etc., as if it was starting for the first time). But then what all triggers that action I think should remain for the Delft Team -- it's not clear whether resize should always cause this; maybe some visualizers can continue on a different-sized canvas while others need to renew. Similarly, do all parameter changes cause a renew, or just some of them? What about when the sequence changes? Should there be a "renew" button on the screen at all times? etc. etc.

katestange commented 5 months ago

I believe the time element is valuable in Mod Fill and was intentional.

gwhitney commented 1 month ago

This should be taken care of for every visualizer in their overhaul for alpha (indeed, it's one of the main reasons for the overhaul), so setting the milestone accordingly.