ambassador at fourthworld.com
Thu Feb 25 12:08:34 EST 2016
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
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.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the Use-livecode