LiveCode Forums.

Well, I sure don't think the question is silly, I just think we're not getting you to visualize the problem very well.

You appear to be thinking about this problem in a straight line method, and assume that the availability of that line is infinite and merely straight across and only the height of each field, but this isn't the case . Everything, whether a physical object or digital one, has limits.

Maybe comparing your fields to real world objects might help. Let's say your fields were books instead, and your monitor was the bookshelf, and your video card the librarian putting said books on the shelf.

Because of the law, the library can only have fullsize bookshelves in it, 6 rows high, in lengths of 6' (or 2 meters for everyone else). To make it worse, the law further states that your librarian has to build each and every book shelf manually.

You have decided that it would be nice to have your librarian put the books on only one row of shelving, and further that row of book shelves has to extend in a straight line across the library.

Are you beginning to see where this is going? If not, draw it out, I'm sure you'll get the idea.

Yours is not a silly idea at all. It reflects some of the best thinking of The xTalk Way, which favors concrete WYSIWYG solutions wherever practical.

It just happens that the specific task here isn't practical, given how the groups are handled internally.

One of the few downsides to The xTalk Way is that by making our work easy it hides from us the complexity of the engine's work.

To expand the current limit is far more than creating a buffer size that would be problematic. It would require a thorough rewrite of the engine's group object so that it only buffers what's seen on screen at any given time. Which you've already done in script.

The group object is described as using a coordinate space defined by a signed 16-bit integer.

You can tell the engine to exceed its defined bounds. But you may not expect how it will respond.

Let us know the result of that experiment...

Hi and thanks for the explanations,
I dont know the inner workings of LC and how much of a reworking it would be to use 24bit integers, but my hunch is that it needs to come sooner or later. If I am not totally mistaken with HTML/CSS it seems to be possible to use much larger integers for coordinates of objects: https://jsfiddle.net/JamesD/7FaJq/1/. I will also have a look at what LC's comeptitors have to say about this. In a Unity forum I read someone complaining about the 32bit limitation for coordinates...

Best
Oliver

okk wrote: Fri Apr 24, 2020 3:13 pm I dont know the inner workings of LC and how much of a reworking it would be to use 24bit integers, but my hunch is that it needs to come sooner or later.

Possibly. But as I'd written in my first reply here:

"Most apps made with anything else would solve this problem through paging the displayed items, rendering only what the user can see at any given time."

A group buffers everything in one composite bitmap. Larger coordinate space would require a different model, as described above, and as you've done in script.

Not impossible, but given that few apps need to ask the user to scroll more than 30 feet I wouldn't hold off on development plans waiting for it.

As you found with your experiment, the scrollbardrag message handles things quite nicely, allowing us to create just about any exceptional model we need for any exceptional circumstance we encounter.

If I am not totally mistaken with HTML/CSS it seems to be possible to use much larger integers for coordinates of objects: https://jsfiddle.net/JamesD/7FaJq/1/.

True, and the same is also true with LC fields. You could put the entire Bible or similarly long text into a field, and you'll find that after a brief pause calculating line wrapping it scrolls beautifully.

Specific use cases lend themselves to specialized solutions.

Browsers began as glorified text fields, and in the early days their capabilities were hardly any more advanced than a LiveCode field.

Over time they've evolved of course, and along the way many browser rendering engines died because they're tremendously expensive to produce. Today there are only three in common use, financed by the wealthiest software companies on the planet.

So yes, it's possible to change LC's group rendering model.

And yes, it would be a very expensive bit of engineering, with not only significant direct cost but also a bigger opportunity cost, the features others are asking for that would be postponed to rewrite the group object.

So for the moment, when we have uncommon needs we do a little scripting.

Not everything possible with LiveCode is limited to what's available by clicking a checkbox ( though with a well-crafted script it can become so, as the DataGrid exemplifies).

I will also have a look at what LC's comeptitors have to say about this. In a Unity forum I read someone complaining about the 32bit limitation for coordinates...

I'd be get interested to learn what you find. Please keep us posted.

Matthias Rebbe did a beautiful stack that paged a large image flawlessly, many years ago. I remember being very impressed with the results. It might be on LiveCode Share and its scripts might be useful in this case. Sorry I can't remember the name of the stack, but searching for his name might reveal it.

Hi all, thanks for the comments. I got my timeline scrolling nicely and all is fine. I did not know that Sample Stacks in the IDE is actually called livecode share. Thanks for the tip. I only found 2 stacxks from Matthias, no large picture scroller unfortunately. Best. Oliver

Hi Oliver,

a similar problem of caching/reloading when displaying a 360 degree panorama (on image) as endlessly scrolling is here

viewtopic.php?f=49&t=13430#p64561

Though it is not exactly your problem. But it shows how to switch the imgage when scrolling horizontally.



Kind regards

Bernd

Thanks Bernd. This forum is full of small treasures. Best. Oliver