Unusual slowness when changing cards

[mokogobo]

Hello.

I've got a single stack with about 20 cards in it, and when I switch from any card to any other card, there is an unusually long delay before the destination card is shown. The wait is approximately 2-4 seconds (always, it is this long).

I do not have any terribly large images in any card, and on most cards, I have only text and between 3-5 rectangles used to make a nice interface.

Any ideas what could be causing this slowdown? In general, are there practices that should be followed or avoided in order to prevent slowdown?

Any tips, pointers, etc. will be greatly appreciated.

[Klaus]

Hi mokogobo,

any "preopencard/opencard/closecard" handler that might cause this?

[mokogobo]

Hi mokogobo,

any "preopencard/opencard/closecard" handler that might cause this?

I do use all of these messages, but not on all cards, and most of the work I do in them is very small (e.g., changing a variable value, clearing a form field).

I watched the messages as I switched between two of my "regular" interface/navigation cards and saw a huge number of messages, mostly "cRevGeneral". I read that there are normally a lot of these, but they were being shown for at least a minute or two. Is that normal?

It might be helpful to note that even when I click a menu option from the Mac OS menu on the top of the screen, there is a delay for about a second that usually isn't there. This is only when I'm using this particular stack in RunRev. "put the frontScripts" in the Message Box returns four different items (none are mine). I only use one frontscript, which does VERY little (looks at the mouseUp message). Is it normal for these other frontscripts to be present?

[mokogobo]

As a test, I removed all front scripts and then added only my custom front script. Things operated a speed that seemed normal when I did this. I created a completely new project and without adding anything, I opened up the Message Box and typed "put the frontScripts" and I was returned the following lines:

button id 1117 of group id 1016 of card id 1002 of stack "/Applications/Revolution Studio/2.8.1-gm-3/Toolset/revlibrary.rev"
button id 1116 of group id 1016 of card id 1002 of stack "/Applications/Revolution Studio/2.8.1-gm-3/Toolset/revlibrary.rev"
button id 1109 of card id 1002 of stack "/Applications/Revolution Studio/2.8.1-gm-3/Toolset/revlibrary.rev"
button id 1042 of card id 1002 of stack "/Applications/Revolution Studio/2.8.1-gm-3/Toolset/revlibrary.rev"
button id 1113 of card id 1002 of stack "/Applications/Revolution Studio/2.8.1-gm-3/Toolset/revlibrary.rev"

Is this normal?[/quote]

[Klaus]

Hm, yes these scripts are "normal" and "normally" they do not slow down the complete app.

Sorry, no other idea in the moment :-/

[mokogobo]

Hmmm. If anyone else has any ideas, I'd really appreciate it. I've tried "lock screen" in the "on closeCard" messages and "unlock screen" in the "on openCard" messages for the cards, and this didn't help speed things up.

[keyless]

This might help:
http://forums.runrev.com/phpBB2/viewtop ... highlight=

But I was only having a slowdown going to the second card only, not everytime like you are having.

[Bernard]

do your cards have images on them? It could be that.

Are you using any 'effects' (e.g. wipe left, etc)?

[mokogobo]

do your cards have images on them? It could be that.

Are you using any 'effects' (e.g. wipe left, etc)?

Hello. I apologize for the delayed response. I do have images on the cards, but the largest image is 1024x768, which is the size of the card. This doesn't seem excessive. Is it?

[mokogobo]

Hello. I found the problem. I was not properly deleting groups that I'm creating dynamically for temporary use, and a huge number of these was created with the "backgroundBehavior" property enabled. I deleted these and am in the process of reworking my code. I should have noticed this, but I was not aware that "create group myGroup" set the group with the backgroundBehavior property enabled. Anyway, everything runs like a charm now.

By the way, since there was a ridiculous number of backgrounds/groups, I deleted them by using the following script in a button:

Code: Select all

on mouseUp
  put the backgroundIDs of this stack into background_ids
  split background_ids by return
  repeat for each element b_id in background_ids
    set the cantDelete of background id b_id to false
    delete background id b_id
  end repeat
end mouseUp

Thanks to all who gave me pointers. I did learn a bit about optimization by researching possible causes for this problem!

[mokogobo]

...I was not aware that "create group myGroup" set the group with the backgroundBehavior property enabled. Anyway, everything runs like a charm now.

After a bit of testing, I found this to be incorrect. I created the group with

Code: Select all

create group myGroup

then added various graphics, fields, etc. and removed it with

Code: Select all

remove group myGroup from this card

which removed the group from the card where it was created, but this also stored it so that it was available to "place" on other cards (and visible from the Object > Place Group submenu in Revolution). To completely destroy the group, the following code can be used:

Code: Select all

delete group myGroup

M.G.