I've not (yet) had to deal with particularly complex resize needs, so
I've never run into the problem of not keeping up.
But I've always had in the back of my mind the following idea (i.e.
check it out, don't assume I know what I'm talking about :-)
the system is going to throw a series of resizeStack message at you ...
in the time it takes you to do one (if it's time-consuming), there may
be multiple more waiting for you ...
So - at the start of a resizeStack, it may be worth checking the
pendingMessages to see if there are already further resizes in the
queue, and if there are, just skip the current one (since you will
almost immediately do the next one).
-- Alex.
On 14/03/2016 18:34, Terence Heaford wrote:
On 14 Mar 2016, at 16:59, Richard Gaskin <ambassa...@fourthworld.com> wrote:
on resizeControl
refreshChart
end resizeControl
Obviously, this works but does not cure the occasional flash that occurs when
reproducing the chart.
I suspect perhaps the script along with all the resizeControl messages is
making it difficult for the engine to keep up?
I can’t think of another reason. I am sure the script could be optimised.
Could anyone suggest areas that are particularly time consuming that I could
look at that may improve performance.
I am already using lock messages.
Thanks
Terry
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
