DataGrid

[Richard Gaskin]

Terence Heaford wrote:

> Do you believe that the performance of the LiveCode scripting engine can be improved to achieve a
> full screen smooth scrolling DataGrid similar to NSTableView in Xcode/Objective-C?

Performance enhancements in the engine will likely benefit the DataGrid 
as much as anything else.

But I don't believe it will be possible to completely match C code for a 
control this complex.

It's important to keep in mind that what the DG provides is quite unlike 
anything other list form we've ever seen:

In the olden days (not sure how this is done in Cocoa), custom lists 
were defined in a List Definition resource ('LDEF'), and very complex 
bit of work requiring support for a broad range of hooks.  You'd have to 
use LineTo, DrawRect, DrawText, and dozens of other low-level calls to 
specify in great detail every pixel that gets rendered on screen - and 
you'd do all that in C.

The DG isn't as much like an LDEF as it is more like an infinite variety 
of possible LDEFs, a sort of LDEF framework if you will.

We can use the DG to construct something that looks like any single LDEF 
we come across and wonder why it can't be as fast as the one we're 
emulating.  But unlike any single LDEF we can change the appearance and 
behavior of our row contents in a nearly infinite variety of ways, 
whereas with an LDEF the form it's hard-wired to provide is the only 
form you can get.

If someone were to write a sort of meta-LDEF that allowed us to define a 
row without hand-crafting every pixel in C, and then use that definition 
within the meta-LDEF to render it and handle messages within it, and 
then write that for all supported platforms, we'd likely see a 
performance boost.  Given the overhead of interpreting the row 
definition it would still be possible to write faster LDEFs that used 
only one hard-wired row layout, but it would get much closer than what's 
possible in any high-level scripting language.

The challenge is:  who has time to write such a beast, and to write it 
seven times (Mac, Windows, Linux, iOS, Android, Raspberry Pi, HTML)?

LiveCode Builder will reduce the workload needed for that, once editable 
text fields become part of its primitives set.  But even then it's not a 
magic pony:  any high-level scripting language will require more 
computational steps than executing machine code compiled in fixed form 
from a lower-level language like C.

So while I have no doubt the eventual replacement for the DG written in 
LCB will be a very valuable undertaking, it won't solve every aspect of 
this inherently complex problem, a problem so complex I've not seen any 
solution like it anywhere else.

Personally (and speaking out of an admitted broad ignorance of many 
engine details), I would imagine some of the greatest boots to 
performance for DG scrolling may come from things not specific to the 
DG, but more generalized in the way rendering buffers are maintained for 
all groups.

That may be an area the team could explore down the road after the 
higher-priority items (Mac 64-bit, themes, general text performance, 
etc.) are locked down and shipped in v8.0.

And it is for those reasons I keep encouraging everyone to please use 
v8.0dp in your daily work today.  Only by having all of us apply the new 
engine to our work can we assure its fitness for the specific tasks we 
ask of it.

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