ScreenRect bug or not

[Richard Gaskin]

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