Cheesed off by 32xxx

Richmond Mathewson richmondmathewson at gmail.com
Mon Apr 3 14:26:42 EDT 2017


Thanks for such an informative posting.

On 4/3/17 9:58 am, Mark Waddingham via use-livecode wrote:
> 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.

Oh: I am perfectly capable of pumping out 8703 buttons, that is NOT the 
problem.

The problem is to have them placed sequentially one above the other in a 
"monster list" grouped into a 700 pixel high group with
a vertical scrollbar: even that, as such, is not the problem: the 
problem is thatthere is no way I can stack those buttons up
vertically prior to grouping them.

128*8703 not necessary at all (quite apart from the fact that I'd be 
even more out of my box
than I am already to contemplate that).
>
> 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.
>

Best, Richmond.



More information about the use-livecode mailing list