quickly wiping a card
Geoff Canyon
gcanyon at gmail.com
Sun Sep 15 23:33:11 EDT 2013
Scott, that runs in about 6ms for me, and the only things faster I could
find were to make sure the objects were in a group and delete the group (as
you suggested) or just create a new blank card and delete the existing
card, and neither of those was faster than 4ms.
On Sun, Sep 15, 2013 at 8:08 PM, Scott Rossi <scott at tactilemedia.com> wrote:
> Hi Mark:
>
> My point was, with messages locked, nothing can be updated until after the
> handler has executed (or you manually unlock messages). So if your
> scripts rely on tracking objects individually as they are deleted, then
> locking messages doesn't make sense. However, the original post
> explicitly mentioned clearing a card as quickly as possibly, and in this
> case, locking messages can make a substantial difference. Otherwise, the
> IDE will track each object as it is deleted. For example:
>
> -- CREATE A COLLECTION OF GRAPHICS:
> -- RUNS HERE MORE THAN 2x FASTER
> -- WITH MESSAGES LOCKED
>
> on mouseUp
> set style of the templateGraphic to "oval"
> set width of the templateGraphic to 200
> set height of the templateGraphic to 200
> set loc of the templateGraphic to loc of this cd
> put millisecs() into MS
> lock screen
> lock messages
> repeat 5000
> create grc
> end repeat
> unlock messages
> unlock screen
> put millisecs() - MS
> reset the templateGraphic
> end mouseUp
>
>
> -- DELETE A COLLECTION OF GRAPHICS:
> -- RUNS NEARLY INSTANTANEOUSLY HERE
> -- WITH MESSAGES LOCKED, COMPARED TO
> -- MORE THAN 3 SECONDS WITHOUT
>
> on mouseUp
> put millisecs() into MS
> lock screen
> lock messages
> repeat number of grcs
> delete grc 1
> end repeat
> unlock messages
> unlock screen
> put millisecs() - MS
> end mouseUp
>
>
> ----------
>
> A couple of other tricks I use when creating or deleting numerous objects
> (call it
> a "collection" for the sake of discussion):
>
> 1) To delete a collection instantaneously at any time, I often create the
> objects of the collection inside a group. When I want to delete the
> collection, I only need to delete the group in a single action, as opposed
> to using a repeat loop on individual objects.
>
> 2) When creating or deleting large collections while in the IDE, I close
> the Application Browser. This stack continually tracks objects in a
> development stack, so closing it can speed up object creation/deletion
> time.
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 9/15/13 4:26 PM, "Mark Wieder" <mwieder at ahsoftware.net> wrote:
>
> >Scott-
> >
> >Saturday, September 14, 2013, 7:23:35 PM, you wrote:
> >
> >> Actually Mark, locking messages is often a good way to speed things
> >> exactly because the IDE doesn't track objects that are added or deleted
> >> until after the current handler has finished executing.
> >
> >Well, you had me going for a while there, but no. If you lock messages
> >the IDE doesn't get the delete<object> message at all. This is what
> >lock messages is supposed to do. Try this:
> >
> >in a frontscript put
> >
> >on deletefield
> > put "deleting" & cr after msg
> > deletefield
> > pass "deletefield"
> >end deletefield
> >
> >Then create a new mainstack with a button and a field.
> >In the button script put
> >
> >on mouseUp
> > delete field 1
> >end mouseUp
> >
> >OK - now that you can see the "deleting" message in the message box,
> >put a new field on the stack again and change the mouse script to
> >
> >on mouseUp
> > lock messages
> > delete field 1
> > unlock messages
> >end mouseUp
> >
> >So yes, locking messages *is* a good way to speed things up in the
> >proper situations, e.g., if you're doing this in a standalone you'll
> >gain a significant boost, but there might be side effects if you try
> >this in the IDE.
> >
> >--
> >-Mark Wieder
> > mwieder at ahsoftware.net
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
More information about the use-livecode
mailing list