Cheesed off by 32xxx

[Richard Gaskin]

One of the beautiful things about making GUIs in LiveCode is that we 
generally get a very satisfying and immediate sense of physicality with 
the controls we're working with:  we envision the user interface, drag 
out controls to match that vision, and we have a one-to-one 
correspondence between what we're doing as developers and what the 
end-user is working with.

Most of the time this physicality lends itself to an uncommonly 
productive workflow.  I was talking about this with Trevor the other 
day, and we both agreed that the direct manipulation of controls in a 
"live" environment, coupled with a language that includes GUI controls 
as first-class citizens, is a big part of why we continue to rely on and 
enjoy LiveCode.

But from time to time, we find particularly ambitious GUI designs that 
become problematic within this paradigm.  Not impossible, but requiring 
us to abandon the comfortable sense of physicality to consider more 
traditional solutions.

As Mark Waddingham pointed out, the memory and CPU requirements for 
working with tens of thousands of objects can be onerous, in some cases 
perhaps prohibitively so.

That's part of the reason why most of the world solves GUI problems 
through radically different means than LC does.

LiveCode does such a good job of maintaining the illusion that GUIs are 
physical objects that we often take it for granted.  But in lower-level 
tools, you're required to be constantly aware that all of that is just 
an illusion - the structs, the buffering, the hit-testing, it's all 
abstraction that only appears physical at the very end of a very complex 
set of processes.

In lower-level languages, most of the time if it ain't on screen it 
ain't instantiated.  They don't even bother.  No need - no one can see 
it anyway.  They maintain just enough info to know when a control needs 
to be instantiated, and then do so only when it will be visible in the 
window.

The DataGrid is a good example of a middle path between the abstraction 
of lower-level languages and the physicality of LC controls:

You can have any number of rows in a DG, but truth be told the only ones 
that actually exist are the ones you're looking at.

Trevor has made very smart of use of fluid scrollBarDrag message to 
populate the visible portion of the group with the controls relevant for 
that scroll position.  Everything out of view doesn't really exist, at 
least not in terms of GUI controls.

It's a non-trivial task to effectively virtualize large numbers of rows 
and instantiate only what's visible on the fly.  He's done an excellent 
job of that.

In addition to being a very valuable part of the LC toolkit, the DG is 
also a reminder that with a little effort we can solve even big problems 
in LC, even though some of the bigger ones require us to set aside the 
perceived physicality and think about things in a more traditional 
computer science way.

I've found, as Mark confirms, that the coordinate space in LC is limited 
to about 32765 px.

Given the power of computers and the ease of using LC, we might 
sometimes see that as a constraining limitation.

But think about it:  at 96dpi that's just under 28 feet on a side - far 
larger than any monitor you can buy, which means far larger than 
anything any user could possibly see.

When we need to work in unusually large spaces, it becomes time to think 
in unusual ways.

By paging rendered elements, as the DG does, we can handle nearly any 
size of coordinate space.

It requires more work to think through a solution that makes sense for 
the design at hand, but just about anything you can imagine is doable, 
even if the worst that happens is that we have to think about solutions 
using methods similar to how the rest of the world has to deal with them.

In the case of the task at hand here in this thread, the solution is 
even simpler:  the DG already provides one way to virtualize large 
numbers of controls for us with minimal effort to use, and it may be 
possible to take advantage of the flexibility of LC fields, with their 
excelling buffering, to do that as well.

But even the in a worst-case outcome, where we'd need to figure out a 
paging mechanism from scratch. I wager that even though it requires more 
effort than just laying out tens of thousand of controls, it can be done 
in LC far more productively than one could do in just about any other 
GUI toolkit.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com