[Feature Request]: curve: layout of animate_curve and animate_3D_curve

[martin-henz]

Feature

Currently we have:

Note the wasted space:

The two items, controls and display, should be arranged vertically instead of horizontally. That would lead to a much more efficient use of screen space.

[martin-henz]

Much better now! Thanks @sayomaki

A small request: At the moment, the width of the animation seems to be limited to the width of the controls. Could we change that so that the animation fills as much of the tab space as possible?

At the moment, we have:

[sayomaki]

I did consider that (stretching the sliders) when designing the change, but it would result in a pretty long bar, especially for those with really large screens.

Therefore, I propose that we can let the slider expand in tandem the page width, but only up to a certain length relative to viewport width, so as to not completely stretch across the whole available length (considering how the rendered model/animation only occupies a fixed maximum length proportional to viewport width, as seen in your screenshot above).

Alternatively, we can adjust the size of the model render output/animation as well (together with the slider length), but that will result in the animation canvas size being inconsistent with all the other modules.

[martin-henz]

I think we are coming to a consensus:

The model widget should expand proportionally to maximize use of available space below the sliders.

Regarding the question whether the sliders should always expand to occupy the whole width or whether there should be a maximal width: I don't have a particular preference. If you find a maximal width more pleasing, please go ahead.

[Cloud7050]

I think we are coming to a consensus:

The model widget should expand proportionally to maximize use of available space below the sliders.

Regarding the question whether the sliders should always expand to occupy the whole width or whether there should be a maximal width: I don't have a particular preference. If you find a maximal width more pleasing, please go ahead.

I have been taking a deeper look at this issue and I think the second part of the enhancement (second part referring to the reopening of this issue) has more in the way of complexity than would initially appear. I am still compiling my findings and will post them shortly.

[Cloud7050]

I did consider that (stretching the sliders) when designing the change, but it would result in a pretty long bar, especially for those with really large screens.

Therefore, I propose that we can let the slider expand in tandem the page width, but only up to a certain length relative to viewport width, so as to not completely stretch across the whole available length (considering how the rendered model/animation only occupies a fixed maximum length proportional to viewport width, as seen in your screenshot above).

Alternatively, we can adjust the size of the model render output/animation as well (together with the slider length), but that will result in the animation canvas size being inconsistent with all the other modules.

If I am understanding Prof Martin correctly, he feels that the width of the controls are fine, but would like the canvas to be even larger so as to use up the remaining tab space available. This is as opposed to the notion of keeping the existing canvas size shown in the screenshot, while making only the sliders wider to use up more tab space.

Currently, the maximum canvas width is not limited by the width of the controls, rather, the controls flex dynamically to match the width of the canvas. (Although, the minimum width of the canvas is limited by how skinny flexbox allows the controls to be.) There appear to be challenges involved with making the canvas larger than in the screenshot which cause this enhancement to no longer be a quick/simple change.

Curves currently seem to render at a fixed 512x512 resolution regardless of actual canvas size. Curves without controls (such as non-animated, non-3D curves) flex freely as there are no sibling controls in the same parent div, but the rendering is only done once, so a larger canvas element results in a blurry image:

As for curves with controls (where interacting with the controls results in a redraw), when the canvas is smaller than 512x512, it renders at a higher resolution than necessary, which is a bit wasteful. Meanwhile, the canvas is technically allowed to stretch larger than that size by way of its CSS styling, but the corresponding fixed width and height properties together with how flexbox works would appear to prevent it from doing so. I believe this is the crux of the problem. Even if we were to force the canvas to appear at a larger size by somehow modifying the canvas properties on the fly, the renderer is still operating at the fixed lower resolution, and this either causes a blurry image or undefined behaviour:

The current CSS styling of the canvases come from the creation of CSG, where I experimented with various canvas sizes and how they could adapt to different tab sizes on different platforms. I believe curve/rune canvas styling used to be different, but with Lee Yi's additions to those modules such as module state, animated/3D and multiple tabbed renders, the same CSS styling as CSG was adopted. In this way, I think the concern of inconsistency with other modules is addressed.

For CSG, the canvas will expand to take up as much of the tab space as possible while avoiding becoming ridiculously large.

• For mobile views, the screen is skinny yet tall. CSS maxWidth will be 70vh
• For web views, the window is typically wide but short. The CSS maxWidth usually in use will be 30vw

Taking those together, the relevant CSS styling for the div containing the canvas is maxWidth: 'max(70vh, 30vw)' (as seen in canvas_holder.tsx). Below are some images illustrating the dynamic sizing and capped width:

Conventional usage (use up all available tab space):

Edge cases (cap the width to avoid the canvas being too large):

CSG is "aggressive" in its rendering in that there is a constant renderer loop running, making it easier to redraw upon all sorts of events such as resizing and user interaction. As part of the loop, the canvas element's properties are also set as needed. I am unsure if curve and especially rune have similar mechanisms that would enable similar behaviour, ie allow the canvas to both appear at a larger size and render at a larger resolution. Respective updates to the rendering mechanism as well as the WebGL portion that I think Ruo Mu wrote may be in order for this enhancement.

To summarise, here are some challenges that may need to be considered to make the curve canvas larger:

• Canvas element width/height properties are not updated dynamically by the renderer, causing the controls + flexbox to limit maximum canvas size to 512x512
• Renderer does not render at a dynamic/larger resolution depending on potentially available space for the canvas element
• Renderer is not triggered for a redraw when the tab (and thus potentially the canvas) resizes

Other possible considerations:

• Resolution/canvas behavioural consistency with the rune renderer

Apologies for the extremely long post, as I kept changing and adding things as my findings evolved. The post was originally meant to be much simpler. But in light of all this information, perhaps it will be fitting to "promote" this topic into its own standalone issue, as a more complex enhancement.

@martin-henz @sayomaki

[sayomaki]

I think in my case I might have missed out on a styling property to set the width of the box containing the interface and model, and have tested modifications to my code to allow the box to expand fully to cover the space given (similar to runes/normal curve modules).

As what @Cloud7050 has mentioned, scaling up pixel-wise and ensuring consistency with other rendering modules that uses WebGLCanvas will definitely be more complicated, this seems more appropriate to be addressed in another separate issue instead.

For now, I have gone ahead to try to scale up both the slider and canvas output to the maximum dimensions available (slider will fill width while maintaining aesthetics, and canvas will scale up to the maximum viewport width/height as mentioned earlier), and I have a sample render of the new updated design.

@martin-henz If this looks alright and well, I will proceed to draft a PR with the relevant changes and clean up the code that is going to be merged.

[martin-henz]

Yes, that's great! Please go ahead. Thanks! Looking forward to students winning the contest with this in place.