LiveCode Forums.

On a new card, with a button with: This takes a long time. Long time. Changing the "mouseColor" to any other function makes it go lickety split.

Craig

Hi Craig,

maybe locking the screen will help?
I bet it does!


Best

Klaus

Here it takes 0.15 ms per iteration.

What OS are you running on, and at what resolution and screen density?

maybe locking the screen will help?
I bet it does!

Klaus, I am insulted. Wait, I have a better idea, how much?

Richard, I am running less that a third of that speed, but even your rate seems awfully slow, no?. It is something to do with this particular function. Oddly, the traverse of the cursor sometimes runs in short bursts of speed, and then back to a crawl, all within the same run. Continued runs will always bring it to the slowest speed, though even within a run in tiny fits and starts, not evenly.

OS 10.6.8. LC 6.6.4

Craig

Hi Craig,

I apologize heavily!

But yes, this is UNBELIVABLE slow!
OS X 10.10, MacMini i7, 8 GB Ram, SSD boot disk and LC 6.7 with this script: I get -> 6041, that's 33.4 ms per loop, same without locking the screen
Well, that should really be faster, not!?


Best

Klaus

I tried both setting and getting other properties that involve color, and none of them cause any delay. It is just the mouseColor.

Klaus, I get about what you do now, two ticks per loop. I do not know why, but today it is working two or three times as fast as it did yesterday. The fits and starts are more pronounced as well, and working in larger "chunks". Do you see this as well, or does your cursor run more or less at an even rate?

Yesterday the cursor just crawled down the screen. taking about 5 ticks per iteration.

All academic I suppose, but should RR be aware of this?

Craig

This is not a special of mouseColor or mouseLoc.
This is rather a special problem of LC in some computations based on rectangles or points.

Let me explain: Say you have a rect (x1, y1, x2, y2).
Simply think of the pixels that have integer points as their LOC. Now you see the problem at once:
With this thinking the topLeft of a card is (1,1) and not (0,0)!

Whenever this is not correctly used for globalToLocal-computations then you get wrong coordinates, that could easily cause a throttling innerLoop that corrects this one-pixel-offset back and forth until recursionLimit or cause a "screen walk" of your mouseCursor.

The first two items (x1, y1) of a rect describe the topLeft of your rect, the named point is *outside* of your rect; the last two items (x2, y2) describe the bottomRight of your rect, the named point is *inside* your rect.

In other words, top and left are 0-based, the bottom and right are 1-based. Whenever this is not used correctly then some "point-within-rect" calculations yield wrong results, and so on ...
[I even saw computations in code from Apple ignoring this (and thus caused one-pixel-offsets).]

Craig. Some are walking their doc, we use to walk our cursor

Hermann.

If what you say is true, then the same issue should arise if I:

"put the mouseLoc", as opposed to "put the mouseColor"

Each of these functions requires the engine to determine the coordinates of the current loc on the fly in each pass, as opposed to some other type of function call that need not deal with that issue at all. But the "mouseLoc" causes no such delay.

I certainly have not tried all possible functions, just a few select ones, like the one above, that seemed pertinent.

Craig

I had different results over handlers and LC versions. Presumably this depends upon what the engine uses, it's own globalToLocal or "directly" an offset that should yield the same result (depends on the current developer).

And, don't forget, the scaleFactor of the stack (which is somewhat buggy until now) could also interfere with your results in newer LC versions. This is, although nothing is scaled by a factor, there could be a different rounding mechanism for some computations with this new factor, what may also cause one-pixel-offsets.

We have to learn for a while not to be "pedantic to the pixel".

So I tried this with a number of different screenMouseLoc values: I made only ten loops, because too many more caused just too much waiting. Anyway, a few tests with much greater numbers produced the same results. The difference in times can vary by up to 50%. Now this says at least that there are no favored values for the loc, that some might have some sort of rounding issue. I would have thought that the engine just takes the explicitly prescribed values anyway, and that these are mapped directly to whatever tables used to identify the pixel color. But I could be wrong.

So I think there is something odd with this function.

Craig

Today my LC 7-cursor crossed on its random walk the stack window, like a fly, from bottomRight to topLeft and then jumped to screen origin (0,0), three times in 5 minutes, then I used LC 6.6.5 and it was gone, all OK.
I'm using MacOS 10.10 and I think LC and Apple are going to have an internal pixel fight about "is topleft pixel inside or outside a stack window?" or "who owns that pixel?"