Cheesed off by 32xxx

[Mark Waddingham]

On 2017-04-02 19:07, Richmond Mathewson via use-livecode wrote:
> The problem, such as it is, is that the Unicode specifications have
> 128 * 8703 slots for glyphs (= a big number my mind cannot cope with)
> and the display in my "CHAR REF" stack is set up to cope with 128
> glyphs a go: hence 8703 buttons.
> 
> Of course I could be racist and leave out the Chinese ideograph slots
> (= about 70%) . . .

You'd probably be okay with 8703 buttons (were there not a co-ordinate 
magnitude limit), but certainly not with 128*8703 buttons.

To give some context...

Each button takes up at least 128 bytes in memory, so:

   8703 buttons is about 1.4Mb - which isn't too bad

   8703*128 buttons would be about 150Mb - which is substantially more

Admittedly, neither of these will 'break the bank' in terms of memory 
availability, even on machines of a G3 Mac vintage, however just storing 
the representation of such things in memory is not the only issue. The 
engine has to do things like:

   - render all the controls on the card

   - perform hit testing when the user clicks or interacts with the card

   - search for controls when you reference them in script

Rendering requires a linear back to front scan of each control, painting 
each one which is within the visible rect of the window the card sits 
in. This means that if you have 8703*128 buttons it will need to perform 
that many steps to render. Additionally, whenever a small amount 
changes, it needs to do this again - as any one control *could* have 
been moved or intersect with the area which has changed (and thus 
require rendering).

Hit testing is similar, although the process is from front to back, and 
stops as soon as a control says it is the target of the mouse / user 
interaction event.

The third case, is the killer though. Looking up a control by name or by 
later requires (on average) number of controls on card / 2 steps to 
perform. If you use the (short) id, then there is a per-stack cache 
which makes the lookup take 1 step if it has been looked up before but 
the normal number of steps if it has not.

In general, we'd never advise using so many controls on a single card - 
and a data-oriented approach which is what others have suggested is 
generally the best approach in this case. i.e. Update the content of a 
small set of buttons as the user browses through the list.

> I wonder if that limit is "cast in stone" or the Livecode people could
> expand it?

Currently engine controls are limited to 16-bit quantities for 
co-ordinates - which means a range of -32768 to 32768. The underlying 
rendering library we use (libgraphics), however, uses floats (32-bit 
real numbers which given an integer range up to around 2^24). So, 
updating the engine to use floats or similar in its co-ordinates for 
controls is certainly possible, just not a task we've undertaken yet.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps