Why is getting mouseColor so slow?

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10354
Joined: Wed May 06, 2009 2:28 pm

Why is getting mouseColor so slow?

Post by dunbarx » Sat Nov 08, 2014 6:06 pm

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
Posts: 14208
Joined: Sat Apr 08, 2006 8:41 am
Contact:

Re: Why is getting mouseColor so slow?

Post by Klaus » Sat Nov 08, 2014 6:54 pm

Hi Craig,

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


Best

Klaus

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10057
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Why is getting mouseColor so slow?

Post by FourthWorld » Sat Nov 08, 2014 6:59 pm

Here it takes 0.15 ms per iteration.

What OS are you running on, and at what resolution and screen density?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10354
Joined: Wed May 06, 2009 2:28 pm

Re: Why is getting mouseColor so slow?

Post by dunbarx » Sun Nov 09, 2014 12:30 am

maybe locking the screen will help?
I bet it does!
Klaus, I am insulted. Wait, I have a better idea, how much? :twisted:

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
Posts: 14208
Joined: Sat Apr 08, 2006 8:41 am
Contact:

Re: Why is getting mouseColor so slow?

Post by Klaus » Sun Nov 09, 2014 3:24 pm

Hi Craig,

I apologize heavily! :D

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 8)
Well, that should really be faster, not!?


Best

Klaus

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10354
Joined: Wed May 06, 2009 2:28 pm

Re: Why is getting mouseColor so slow?

Post by dunbarx » Sun Nov 09, 2014 3:56 pm

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]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm

Re: Why is getting mouseColor so slow?

Post by [-hh] » Sun Nov 09, 2014 10:51 pm

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 :-)
shiftLock happens

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10354
Joined: Wed May 06, 2009 2:28 pm

Re: Why is getting mouseColor so slow?

Post by dunbarx » Sun Nov 09, 2014 11:40 pm

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]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm

Re: Why is getting mouseColor so slow?

Post by [-hh] » Sun Nov 09, 2014 11:52 pm

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

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10354
Joined: Wed May 06, 2009 2:28 pm

Re: Why is getting mouseColor so slow?

Post by dunbarx » Mon Nov 10, 2014 12:33 am

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]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm

Re: Why is getting mouseColor so slow?

Post by [-hh] » Tue Nov 11, 2014 4:11 am

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?" :-)
shiftLock happens

Post Reply