Detect the end of a stack resize

[doobox]

Hi there,

I really want to use liveResizing of the stack. It looks far better for the UI and performance for the majority of my UI is just fine during the resize.

However... There is one user created element visible in the UI at most times. An image the user drops in.
I have a handler that is resizing this image by referencing the original i keep off screen.
This handler just can't cope with being called so often during a stack resize, and performance grinds to an unacceptable level during the stack resize.

So what id like to do as a workaround is not actually trigger the slow handler from the resizeStack message handler, but i must run it once when the stack has finished resizing.

Seems like catch 22, as without live resizing, you can detect the end of a stack resize, but with, you can't. At least not from a LC message that i can see.

Hoping someone has a method of detecting the end of a stack resize, when using liveResizing true.

[bn]

Hi Gary,

that is a bit tricky. The only way I found it to trigger a send in time handler that keeps track of the last resizeStack message and if the last message arrived > 150 milliseconds it triggers a "doImageResize"

The time intervall is settable in the script of the card, the "doImageResize" handler just sets the image to the right of the card. All the logic is in the card script. Depending on your needs it could also go into the stack script.

Kind regards

Bernd

[bn]

Gary,

did you see this?

Kind regards
Bernd

[doobox]

Just been implementing it there Bernd.
Works really well in testing. At least it does what i asked.

Code: Select all

on resizeOccured pTime
   if pTime is not empty then put pTime into sLastResize
   if "resizeOccured" is not among the items of the pendingMessages then
      send "resizeOccured"  to me in 1 millisecond
   end if
   if (the milliseconds - sLastResize) > 150  then
      put false into sStartedStackResize
      repeat for each line aLine in  the pendingMessages
         if aLine contains "resizeOccured" then cancel item 1 of aLine
      end repeat
      setCookieCutterImage
      set the visible of graphic "overlay" to false
      exit resizeOccured
   end if
end resizeOccured

I dropped the wait to 1 millisecond if no pending messages match.
Have you done much testing to get the figure of 150 milliseconds between resize messages.
It would be good to get that as low as possible.

I seem to be seeing about a 500 millisecond delay between lifting the mouse and seeing my "setCookieCutterImage" fire.
I need to do a bit more digging to find out why.

[bn]

Hi Gary,

I tried your code and it is just as fast as mine. Though you send too many resizeOccured by placing it above the exit condition. You could reduce the 150 milliseconds to say 50 and set the sampling interval to 10.
Apparently when resizing, at least in MacOSX the resizeStack message is fireing almost continuously, even when the mouse does not move. (see dictionary). In my first testing I was swamped with messages, that is why I was careful to get rid of them.
Any visusal under about 100 milliseconds is not perceived as delay.

That said I don't think the delay is in the code you posted but in the rest of the code, did you try a lock screen? Is the image rather large?, do you resample at 'best'?

Also try to block the "pass resizeStack" line if you don't use it further up, it generates a lot of resizeStack messages. (why?)

Kind regards
Bernd

[doobox]

Yes i am resampling at "best"
And the image could potentially be massive, a full frame camera image for example, anything the user wants to drop in there.
I have been testing with images around 1280x 900, around 400kb.

I think it must be the fact that the resizestack message is passing up the chain that causes the delay i am seeing, as i have a field that fills from the first line of setCookieCutter and thats where i am seeing a delay of around 500, when
at first glance you would expect that field to fill with a max delay of 150.