Canvas Limited to 32767

[Richard Gaskin]

I'm all for more freedom, but the RAM requirements make any practical 
use of extended coordinates a less trivial problem.

Most programs handle this by paging. It may look like one contiguous 
region on screen, but as you're scrolling it's dumping chunks that fall 
out of view and rendering chunks coming into view, so the total viewable 
space is well within practical memory limits.

The DataGrid shows one example of how to virtualize a scrollbar, using a 
non-scrolling group with a separate scrollbar, and some clever coding to 
make them work in sync.

With that, you can do like other programmers do, paging in an out the 
parts you need when you need them. Only we get to do it in script.

If done in the engine it's the same algo, which AFAIK is very different 
from how groups are buffered now.

So "just" changing from 32k to 64k isn't as easy as putting the word 
"just" in front of it might make it seem. :)  It would require the 
engine team to write a very different buffering algo, a lot of extra 
work for a few edge cases not handled by what's in place now.

No doubt the team could do it, but I don't think it would be simple.

And given the low ROI relative to other priorities, if it went into the 
work queue I wouldn't expect to see it for a long time.

Maybe Mark Waddingham can chime in if I'm overestimating the difficulty, 
but I suspect scripting you own paging system with a virtualized 
scrollbar is something you could do yourself in a fraction of the time 
it would take to wait for it from the engine team.

-- 
  Richard Gaskin
  Fourth World Systems



Ralph DiMola wrote:

> Richard,
> 
> This design was done for one not to involve a lot of coding (App was free
> development but we get a cut of each sale and it has worked out well for
> us). Also there could be a reason to see the entire list but of course there
> are other ways to do this as not to hit the limit. As far as device memory
> is concerned I don't want to go to 2^31 but I am missing the cut by a couple
> thousand pixels. If we had 2^31 it would be up to the developer to keep the
> performance under control rather than apps breaking for 2 pixels over the
> limit.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdimola at evergreeninfo.net
> 
> 
> -----Original Message-----
> From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf
> Of Richard Gaskin via use-livecode
> Sent: Tuesday, October 06, 2020 2:50 PM
> To: use-livecode at lists.runrev.com
> Cc: Richard Gaskin
> Subject: Re: Canvas Limited to 32767
> 
> Glad it's not the funky mobile field workaround.  That's such a horrible
> experience for developers that even the act of documenting it should have
> been a red flag to go back and refine the field buffering for the few cases
> where that put-it-in-a-group recommendation is actually needed.
> 
> In your case, you have a huuuuuuge canvas, with users expected to scroll a
> region about 32 feet.  That's a lot of scrolling.
> 
> So in addition to the memory hit of buffering such a large region (32767
> * 32767 * 4 + whatever other overhead comes into play with buffering), in
> most layouts it would be a usability impairment to ask users to keep
> scrolling that much.
> 
> So maybe the team could switch the address from 32 to 64, but it still leave
> us with the question:
> 
> - Would a user have that much RAM?
> 
> - Would the user be able to use such a large canvas without acquiring
>    RSI? ;)
> 
> I don't know your layout, but I do know you, and you're not the type to make
> things hard for users, so I'm assuming there's something about this
> uncommonly-large scrolling that fits well with the app's requirements.
> 
> But what we do know is no monitor can show it all, so the content is already
> effectively paged into view as-needed.
> 
> Could the content paging be provided through some other UI? For example, if
> those controls fit into logical groupings, might different sets of them be
> placed into separate physical groups, perhaps accessed via tabs or a list?
> 
> If it's truly necessary to have one vast plane to hold everything, could you
> handle paging internally while still providing the appearance of a
> contiguous group, similar to how the DataGrid does it?
> 
> --
>   Richard Gaskin
>   Fourth World Systems
> 
> 
> 
> Ralph DiMola wrote:
>  > Desktop and mobile. It's a scrolling group with many sub-groups each
>  > with 1 or more fields. Sometimes the height of the main group > 32767.
>  >
>  > It's the result of a proximity search and in dense areas users are
>  > getting hosed by this limit. Customer is screaming (but don't they
>  > always).
>  >
>  > Ralph DiMola
>  > IT Director
> 
> 
> -----Original Message-----
> From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On 
> Behalf
> Of Richard Gaskin via use-livecode
> 
> Ralph DiMola wrote:
> 
>  > I just ran head first into this. Could someone explain why other than 
>    > moving from an int16 to an int32 this is such a challenge? This 
> should  > have been addressed during the refactoring of the engine.
> 
> Is this for the weird recommended mobile workaround of putting a text 
> field into a group just to have it scroll, or something else?
> 
> --
>    Richard Gaskin
>    Fourth World Systems