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 ____________________________________________________________________ ambassa...@fourthworld.com http://www.FourthWorld.com _______________________________________________ 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
