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.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
