Replies: 5 comments 1 reply
-
From Kate:
|
Beta Was this translation helpful? Give feedback.
-
And from Glen:
|
Beta Was this translation helpful? Give feedback.
-
After discussing your question more, @gwhitney, @katestange, and I have decided what we want to happen. The visualizer can either (A) say it doesn't care about the aspect ratio, or (B) ask for a particular aspect ratio. In response, the app gives the visualizer a single canvas, chosen as follows. A) If the visualizer doesn't care about the aspect ratio, the app chooses the canvas dimensions however you want. B) If the visualizer asks for a particular aspect ratio, the app provides a canvas of the desired aspect ratio, with the largest reasonable dimensions. You get to decide what's reasonable. For example, if you think that the canvas should never take up more than 4/5 of the height of a mobile screen, provide the largest canvas that satisfies that constraint. Does this description make sense, and does it seem doable? p.s. While discussing this question, we also thought about helping visualizers respond to canvas size changes. I've started discussion #335 to brainstorm about this. |
Beta Was this translation helpful? Give feedback.
-
I've read over your proposed solution, and it seems quite simple yet elegant, and we'll definitely move forward with it. The only major difference between this solution and the one proposed earlier is that if a canvas asks for a certain aspect ratio, it will now be given only the largest canvas of that aspect ratio, and is unaware of the potentially unused outside space. In very niche settings, some visualizers could take advantage of this extra space, but we agree in retrospect that your solution is elegant enough that anything more complicated doesn't make too much sense. |
Beta Was this translation helpful? Give feedback.
-
As the settled-on solution is implemented in ui2, closing. |
Beta Was this translation helpful? Give feedback.
-
visualizers should be able to request aspect ratios, but it remains unclear whether the app should be forced to provide a canvas of said aspect ratio. We found that in both cases, some issues arise:
We believe we have found a third solution which might be more fitting. In this solution, the visualizer asks for a canvas of a certain aspect ratio, and the app then returns two canvases: an abstract canvas and a "true" canvas. The abstract canvas would be a view into a true canvas and always have the desired aspect ratio, while the true canvas is the full canvas that is actually given to the visualizer. That way, visualizers have the ability to choose between a simple implementation using the abstract canvas or to take advantage of the full canvas at the cost of doing dynamic aspect ratio calculations.
This opens the door for a new (more custom) visualizer interface, possible one that sits on top of P5/canvas API, which would take time but could greatly simplify visualizer creation and make them more consistent both with the app and with one another. This wouldn't invalidate previous visualizers, but would be an additional layer on which new visualizers could be made more easily.
Beta Was this translation helpful? Give feedback.
All reactions