Terence Heaford wrote:
> I am pretty sure Live Resizing should be the standard way of doing
> things but I have to say that LC’s performance in this area is quite
> poor.
> I have my stack at a small size to improve the scrolling speed of a
> table but when I switch to another card that displays charts it is
> sometimes preferable to have a larger chart which I have created in
> a group. I have to redraw the charts when the stack is resized and
> this is where LC’s performance is poor. The stack stutters slightly
> as it is resizing.
I've seen things like that now and then, rarely as bad as Apple's Garage
Band but below what I like to give to customers.
Fortunately, in each case I found things I was doing in my scripts that
caused redundant redraws - once I fixed those, even complex layouts with
multiple DataGrids were pretty smooth.
DataGrids are a very challenging case, consisting as they do of so many
controls. Since you're only using the native field object I'll bet we
can get your layout resizing very nicely.
Are you able to post the stack somewhere, or at least the resizeStack
handler so we can see what it's doing?
> Now for some heresy. I also have Xojo (purchased with the last offer
> for £12) with the same programme running and this does not have the
> stutter LC does.
You won't hear cries of "heretic!" from me. Most of us use multiple
languages. I've been in the biz long enough that I no longer use
proprietary formats for anything I care about (seen too many apps come
and go, and I need to truly own my data), but the other half of my time
is spent in JavaScript, and lately a lot of bash. Learning new things
keeps us youthful. :)
Each language exists becomes it does something better than the others,
but none of them is a magic pony, not even LiveCode, nor Objective C nor
anything else.
In terms of performance, with Xojo's data typing requirements we'd
expect better performance in some areas of raw computation, like image
convolvers. But in other areas, like text parsing, the showdown we had
here a while back was more or less a wash, which we would also expect
because much of what we do in LiveCode is really just triggering
highly-optimized routines in the engine that were written in C++ and
compiled with the super-smart Clang.
Rendering is in many respects language-independent, driven by factors
far more complex taking place at a higher level of the implementation.
> I really prefer scripting to Objective-C and Xojo because I have
> worked with SC for so long but always seem to come up against a
> performance limitation at some point. Ah well.
In recent years Mark Lucas has done some great work on SC, and if it
covered as many platforms as LiveCode I'd probably still be using it
today. But Mr. Lucas is very passionate about OS X, and his opinion
about Windows and its API is, well, let's just say not suitable for
posting here. :)
> I don’t know if you remember the discussions over DataGrid and the
> Basic Table Field but pending release of the update to the Basic
> Table Field to include for right alignment I have changed to this
> control because of the improved scrolling speed when compared to
> the DataGrid.
>
> Interestingly while testing the stack in LC 6.7(dp4) I have noticed
> a significant increase in scrolling speed of the Basic TableField in
> the order of a 15-25% improvement when compared to LC 6.6.1.
>
> Within this stack I have pie charts created out of LC objects and
> having just measured the milliseconds from the start of creation to
> display, there is a 12% improvement comparing LC 6.7 with LC 6.6.1.
Not surprising, given the attention the team has been putting into the
rendering algos.
Have you benchmarked 6.6.2rc6? While the changes aren't as deep as in
later test versions, you may still see a boost from improvements to the
tiling algo they use.
> I am presuming this is because of a change to Cocoa and streamlining
> the base code of LC.
Not necessarily. In fact, I'd be surprised if Cocoa made very many
things faster in itself, since Cocoa is only optimized for
strictly-HIG-compliant layouts, and doesn't play nice with the sort of
flexibility LiveCoders demand.
For example, consider the infamous pulsing default button:
Any animated effect will take more CPU load than a static one, and even
Apple's best effort in their own apps tends to bump CPU load by about
8-9% whenever a pulsing default button is visible on screen.
But their API for this insists on antialiasing only against a blank
region of the window using whatever default background pattern/color
they happen to be using in that version.
Try telling anyone using an xTalk that they can't put a default button
on top of a graphic, or an image, or even a movie if they like.
We xTalkers are used to having this level of flexibility, but it would
mean antialiasing artifacts if the engine used only the OS routines.
So instead the engine has to do an extra step, rendering the control
into an internal buffer - outside of anything the OS normally handles
for us - so that they can composite it nicely with whatever else may be
beneath it.
The result is a CPU load of about 13-15%, more than Apple's but
necessary unless RunRev were to start restricting what people could do
with their layouts as narrowly as Apple's APIs expect.
> This is a significant improvement which I hope would be maintained
> and perhaps improved further as the Cocoa based LC progresses?
>
> Do you know which version will be the first to receive the right
> alignment in the Basic Table Field?
I believe that will be in 7.0, since it's dependent on other changes
made for Unicode.
> Also while on the subject of speed (perhaps another thread) but is
> there an intention to speed up the script editor as I find the
> scrolling painful?
There is an IDE rewrite underway, and a very large-scope effort to
improve overall rendering.
The rendering effort includes a shift from the tile approach they began
with to a layer-based model that not only fits better with the Skia
engine they're now using, but has a few other advantages in terms of
being able to optimize a broader range of use-cases.
Additionally, significant effort is ongoing for all text-handling
routines, to minimize the impact Unicode inevitably requires. Ideally
this would mean that Unicode rendering would become close to what we
have today with Latin-ISO, while Latin-ISO becomes blazingly fast.
But as you can imagine, that's a lot of R&D, so not likely to happen in
the 6.x series.
For now, I've turned off colorizing in the script editor and I'm quite
happy with it. Never really depended on colorization anyway, so it's
not something I miss.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
_______________________________________________
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
