erratic movement of controls with repeat

[dunbarx]

This has been the case for a while.

Make two buttons. In the script of btn 1:

Code: Select all

on mouseUp
   set the loc of btn 2 to "100,200"
   
   repeat 300
        set the loc of btn 2 to (item 1 of the loc of btn 2) + 1 & ",200"
      wait 1 millisec
   end repeat
end mouseUp

Click btn 1 a few times. The rate of movement, never smooth, changes radically over several clicks, slowing to a crawl after a handful or so. Keep going; it will "reset" itself, and start that sequence all over again.

In HC, the travel is very jerky, but does not change from one incarnation to the next.

I know LC is not an animation program. How do it know how many times the user has clicked that button? What builds up internally, that seems to clear itself regularly?

Craig Newman

SIDENOTE: HC will not compile the above handler. I must either use a "do" construction, or:

Code: Select all

...
get (item 1 of the loc of btn 2) + 1 & ",200"
set the loc of btn 2 to it

Which is much the same thing. LC parser a bit more forgiving?

[richmond62]

I know LC is not an animation program

I didn't know LC was a program at all: I thought it was a programming language wrapped up in an IDE.

It is possible to do animation on my 1981 BBC Micro Model B using BBC BASIC . . .
as it is in most other programming languages.

One should be able to perform animation in LiveCode
that is less clunky than what I manage on my BBC computer, err, shouldn't it?

[jacque]

Repeat loops are slow and waiting inside one is slower. The repeat loop is blocking besides, never a good thing. You could try "wait 0 with messages" which at least will allow the engine to clean up inside the loop. More importantly, set the button's layermode to dynamic and set acceleratedRendering to true so that the button will be cached.

"Move" of course is optimized for animation. You'd still want to set up acceleratedRendering and dynamic layermode for that. All animations work better when the object is cached in memory.

[dunbarx]

Jacque.

All good stuff. But that is not the point of my post. I know about the traps in waiting for things.

Why does the process change over several iterations? I was wondering if something internally was loading and sticking, randomly, and then flushing itself now and then. It is a question of understanding, and being confident in, the structure of LC.

And as I mentioned, for what it is worth, HC doesn't do this.

Craig

[FourthWorld]

And as I mentioned, for what it is worth, HC doesn't do this.

True, HC doesn't run at all, at least not on any operating system made in the last 20 years.

One of the biggest changes is Quartz and its 16-layer compositing. All the nifty hacks that gave HC a nice feel under the older Mac OS were because it was written by the same person who wrote the OS renderer, QuickDraw. In some cases it used undocumented APIs for the Vertical Retrace Manager for not just rendering but also for sliced interleaving of other operations. Clever stuff, but all gone when Apple tossed it all out to buy NeXT, now reskinned and rebranded as OS X.

Also, remember that HC was monochrome. Sure, an external originally developed by a third party allowed post-rendering blitting of color overlays onto the screen, but that's a radically different process from integrated color as an inherent part of the object buffering/compositing, limited enough that it couldn't handle things like animation. In HC's engine every bitmap was monochrome, a small fraction of the size and horsepower needed for what LC needs to do to support integrated color. Every memory alloc/de-alloc takes not only space but time, and they add up fast.

To really understand the differences between HC and LC under the hood is to understand the differences in the OSes they need to run on. Read the old Inside Mac series, then read Apple's latest docs. All the under-the-hood details can be found in the differences between them.

[dunbarx]

Richard.

Interesting stuff.

But, er, what about the fact that with separate invocations of a single handler, the result is radically different, and even has sort of predictable outcomes, roughly repeatable.

That was the ONLY reason for my post.

I just threw in the HC note because of nostalgia.

Craig

[FourthWorld]

But, er, what about the fact that with separate invocations of a single handler, the result is radically different, and even has sort of predictable outcomes, roughly repeatable.

That was the ONLY reason for my post.

I rarely see those. Do you have an example in mind?

[dunbarx]

Richard.

Do you have an example in mind?

I do indeed. Make the two buttons from the original post.

Craig

[richmond62]

HC doesn't run at all, at least not on any operating system made in the last 20 years.

Well, Yes, but not a particularly helpful answer. And the explanation that follows
seems a bit odd as I was moving things around on a Macintosh LC 475, System 7.1
with 4 MB RAM and a processor that was "slightly slower" than even
the most substandard piece of junk available today, using HyperCard.

[FourthWorld]

Richard.

Do you have an example in mind?

I do indeed. Make the two buttons from the original post.

I see no discernible difference between runs. Hardware and OS version? Maybe someone with a similar setup will be able to reproduce it.

[FourthWorld]

HC doesn't run at all, at least not on any operating system made in the last 20 years.

Well, Yes, but not a particularly helpful answer.

It wasn't an answer to the core question here. It was an observation, in reply to a tangential comment about HC, relevant because there's no way to compare any two software products when they rely on such radically different OS architectures. The observation is factual; whether it's helpful is subjective.

And the explanation that follows seems a bit odd as I was moving things around on a Macintosh LC 475, System 7.1 with 4 MB RAM and a processor that was "slightly slower" than even the most substandard piece of junk available today, using HyperCard.

What are you comparing that to, and using what measurements?

As Craig noted, this thread has nothing to do with HC. It has to do with reasonable expectations of consistent execution given how computers work: they are deterministic systems, in that the same inputs will yield the same outputs. Computers, at least as we know them today, cannot do anything else.

So the real question here is: What factors could cause performance of a given operation to vary between runs?

The assumption here seems focused on LC, but LC is only one part of a very tall tech stack. And since this isn't evident on Linux, if the root cause is in LC it would seem to be specific to the way it interfaces with macOS.

We can't rule out that there is something in LC's internals causing subsequent runs to behave differently, but we also know nothing of the other dozens of processes running on the machine during the test.

I'm not able to reproduce the issue, so there's little I can do to help diagnose it. But if anyone else here can, it may be useful to review machine state across all processes before and after the apparent change.

[richmond62]

this thread has nothing to do with HC

Yet he mentioned it.

Frankly, bringing up HyperCard, 20 years after (as you rightly point out FourthWorld) after its de facto death, is ridiculous.

in reply to a tangential comment about HC

Oh, quite. And has it not occurred to thee that my comment
was a tangential comment to that tangentialism?

Someone getting a bit too sweaty and hot under
the collar round these parts; and it's not me.

So the real question

No, surely not?

This problem is NOT "there" on Linux, so there could be a number of problems:

1. The LC engines for macOS and Windows.

2. macOS and Windows.

3. How macOS and Windows "play ball" with the respective LC engines.

I DO NOT think rabbiting on about what HyperCard could do "way-back-when" is useful at all,
anymore than pointing out that because dinosaurs had neural nexuses in their bums,
yet were vastly more 'primitive' organisms than we are, we have a problem with balancing
when fighting with other people, while the average T-Rex didn't because it's head-brain
didn't have to think about its tail, as its tail-brain (bum-brain?) was doing all the work
down that end.

And because of that, I felt that that disquisition on Quartz, 16-layer compositing, et al was a bit tangential in itself.

[FourthWorld]

This problem is NOT "there" on Linux, so there could be a number of problems:

1. The LC engines for macOS and Windows.

2. macOS and Windows.

3. How macOS and Windows "play ball" with the respective LC engines.

Good diagnostic thinking.

With any anomaly, it's helpful to rule out possible causes to hone in on the actual cause. To that end, it would be helpful to see if this problem persists across:

- IDE vs standalone
- Different LC versions
- Different OS versions
- Different hardware

It seems we've ruled out different platforms, at least as far as Linux is concerned; may be helpful to complete that with a test on Windows 10.

[richmond62]

Good diagnostic thinking.

Possibly; but the problem is going to be how to work out whether the problem is the engine,
the OS, or the interaction between them, as I, for one, know of no way to run a version
of LiveCode without an underlying operating system.

While this type of thinking is useful for relatively simple situations

[Let's pull 'that' fullback out of the football team and see if things improve.]

[Let's play a game of GO with you letting me place 5 stones on the penalty points before we start play.]
-

go.jpg (14.17 KiB) Viewed 6153 times

-
computer systems are not simple.

[FourthWorld]

Good diagnostic thinking.

Possibly; but the problem is going to be how to work out whether the problem is the engine,
the OS, or the interaction between them...

The testing checklist I posted a short while ago may help reduce the solution space considerably.