Strategy for widget with virtual infinite surface

[Enyium]

What is the best strategy for implementing a widget that presents a viewport that's a window into a virtual surface that is quasi-infinite on both the x- and y-axis? This is for a diagram. Similar example for web browsers.

Requirements

• Since the surface is very large (or infinite from the regular user's point of view), I don't need scrollbars.
• I need both x-locked and y-locked overlays, that is, overlays that only scroll on one axis. Even if the user scrolls diagonally (on x- and y-axis at the same time), these overlays must only scroll on one axis while each has a fixed position on the other axis. There must not be effects like moving away from the fixed position first and then being corrected to a fixed position as an afterthought (like it can happen in browsers).
• I may not get float precision issues. During scrolling, the position of the rendered diagram (that's a little bit bigger than the viewport) (and, depending on the element, also the scroll position) must constantly be reset in a way invisible to the user (not affecting what they see), so that values don't drift to higher and higher ones in an uncontrolled manner.

Base

These widgets and built-in elements come into mind as candidates: ScrollView, Flickable, TouchArea. I wonder whether this use case is so special that ScrollView and Flickable aren't suitable. If possible, I also want to avoid having to reimplement functionality like flick-scrolling on mobile, of course. (Should your framework provide helper functions to interpret events to be able to easily reimplement this?)

Excess Elements

When implementing a virtual scroller for the web, one has to render some number of excess elements, because the browser scrolls somewhat (or completely?) independently of the JavaScript code and is quick to show other parts of the scrolling surface, so that you have to pre-render in light of this. Am I right that, with Slint, there wouldn't be a need to render excess elements (at least with a custom TouchArea approach)?

Combination With Animation

If I wanted to implement animated programmatic scrolling to a distant point (i.e., something like scrollTo(), which is an extreme case of animated scrolling on scroll pulses), do you think there's a way to perform the scrolling with a smooth frame sequence, while constantly rerendering the diagram on the virtual surface based on shifted data and correspondingly correcting its position, so that the user can't see the technicalities that're happening? Or would the animation that was started be interrupted by the rerendering stuff etc.?

[hunger]

Wow, that is an interesting problem:-)

What is in that infinite scroll area? "Slint things"? Dynamic "Slint things"? Or maybe custom graphics in some way?

I would probably write some custom component with a TouchArea for interaction and an interface that might be close to a ScrollArea.

[Enyium]

What is in that infinite scroll area? "Slint things"? Dynamic "Slint things"? Or maybe custom graphics in some way?

A timeline, wrapped like text, but scrollable on both axes, because data displayed in vertical flow direction can also be displayed in horizontal flow direction. The data should be displayable in a variety of ways that may be extended over time. But it's basically a bar chart (with borders, gradients, shadows, and all that fancy stuff). Later, Path subdiagrams may be rendered on the timeline.

I would probably write some custom component with a TouchArea for interaction and an interface that might be close to a ScrollArea.

Is Flickable already abstracting too much for me?

Of course, I can (on the y-axis) only render full lines. This would mean a little bit of natural excess (< 1 line on the top and bottom). Could additional excess lines that are clipped possibly be of any use? I could theoretically make line creation out of view rarer by only handling larger blocks of lines at a time. It's not like Slint benefits from reusing elements like diffing DOM frameworks, or is it?

[hunger]

I Flickable might work, but I thought you probably want to control the position and what is rendered yourself. A Flickable would kind of require you to have the entire UI prepared inside the Flickable... That might work or it might just get too big/complex to do.