Canvas Limited to 32767

Ralph DiMola rdimola at
Tue Oct 6 15:24:53 EDT 2020


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

Ralph DiMola
IT Director
Evergreen Information Services
rdimola at

-----Original Message-----
From: use-livecode [mailto:use-livecode-bounces at] On Behalf
Of Richard Gaskin via use-livecode
Sent: Tuesday, October 06, 2020 2:50 PM
To: use-livecode at
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] On 
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

use-livecode mailing list
use-livecode at
Please visit this url to subscribe, unsubscribe and manage your subscription

More information about the use-livecode mailing list