Why is getting mouseColor so slow?

[dunbarx]

On a new card, with a button with:

Code: Select all

on mouseUp
   repeat with y = 150  to 330
      set the screenMouseLoc to "285," & y
      put the mouseColor & return after temp
   end repeat
end mouseUp

This takes a long time. Long time. Changing the "mouseColor" to any other function makes it go lickety split.

Craig

[Klaus]

Hi Craig,

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


Best

Klaus

[FourthWorld]

Here it takes 0.15 ms per iteration.

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

[dunbarx]

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

[Klaus]

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:

Code: Select all

on mouseUp
   put the millisecs into tM
   lock screen
      repeat with y = 150  to 330
            set the screenMouseLoc to "285," & y
            put the mouseColor & return after temp
      end repeat
   unlock screen
   put the millisecs - tM
end mouseUp

I get -> 6041, that's 33.4 ms per loop, same without locking the screen
Well, that should really be faster, not!?


Best

Klaus

[dunbarx]

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

[[-hh]]

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

[dunbarx]

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

[[-hh]]

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".

[dunbarx]

So I tried this with a number of different screenMouseLoc values:

Code: Select all

on mouseUp
   put the ticks into xx
   set the screenMouseLoc to "202,200"
   repeat 10
      put the mousecolor & return after temp
   end repeat
   put (the ticks - xx) / 10
end mouseUp

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

[[-hh]]

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?"