Skip to main content
dolldivine
dolldivine
Inspiring
February 7, 2019
Answered

Which UI setup would use less memory?

  • February 7, 2019
  • 2 replies
  • 844 views

If one has a lot of menu panels, each with a lot of content/buttons, do you think it's better to:

1. have each panel on a separate frame, and go back and forth between them?

(con: everything re-loads each time you re-enter a menu panel, which I know slows down the panel appearing smoothly)

(pro: most of the menu isn't on the stage at any given moment)

2. have all panels appear at once, but make all but one invisible at any given time

(pro: all panels are ready to go. Do not need re-loading, re-formatting)

I don't really have enough knowledge about how Animate uses resources to know the answer.  When things are invisible, are they taking up many resources?  Are their event listeners silenced for the time being or are they all eating up memory, while waiting?

And when you flip through frames, I know the garbage collector removes the event listeners of things that are no longer there, but how long does this take?

Basically, I know for both systems it would probably be ideal to remove all listeners as soon as a panel is switched, but this is really fiddly and I know I would miss a bunch so if there's an easier way to manage everything, I'd love to know...

This topic has been closed for replies.
Correct answer kdmemory

Hi Dolldivine,

I wonder what your project will be like. is it some kind of paint program? With so many colour palettes?

With the new information going back to your original question. Is it better to create each panel in a seperate frame or having them all in one frame and working with visible = true/false or similar means (like animating panels out of sight).

I would definately say it is better to stay in one frame. I'm not so deep into technical memory management matters, but I'm convinced that spreading it over multiple frames doesn't help. It won't be like when the playhead jumps from i.e. frame 1 to frame 2, that everything in frame 1 can be discarded from memory. And the permanent need of gotoAndStop() when interacting with panels won't help either.

     Now about the eventListeners. Considering your numbers, you could end up with 2000+ interactive touchspots. I presume your are not seriously contemplating to provide each one of them with an eventListener, are you? Anyway because of opening vs closing panels (visible or any other method) you will have a hierachy of objects like your panels are movieClips containing all other stuff like touchspots and colour palettes).  What I would do is give each panel one eventListener and one eventFunction and code something like

panel1.addEventListener(MouseEvent.CLICK, clickHandlerPanel1);
function clickHandlerPanel1(evt: MouseEvent) {
    switch (evt.target.name) {
        case "spot1":
            bringOnPanel("panel1");
            break;
        case "spot2":
            //do something when spot2 is pressed
            break;
        case "spot3":
            //do something when spot3 is pressed
            break;
            //.. and so forth
    }
}

This way it would be enough to have 10 - 15 eventHandlers. Easier to manage like removeEventListener(). And we utilize evt.target to detect which touchspot in particular has been pressed.

  • evt.currentTarget = woudl be in our scenario panel1, the object with the attached eventListener
  • evt.target = the object that actually received the click

     Now about your colour palettes. It seems that this section costitutes the largest group of interactive touchspots. "..additional ~70 buttons per colour palette.  Possibly as many as 3 colour palettes per panel." - If this is about some kind of colour picking like using color swatches, you could instead of having so many vector swatch buttons design bitmap colour swatches and utilize the bitmapData class with methods like getPixel() or getPixel32() to detect and set colour values.

I hope this helps a bit

Klaus

2 replies

dolldivine
dolldivineAuthor
Inspiring
February 8, 2019

Wow, thanks! :O

Oh, I'm not just contemplating it.. I've been doing it this way in swf's for years hahaha.  But swf's can take a lot of damage.  Now that I'm also porting to mobile, I'm having to re-think everything for performane.  I make doll fashion type games so yeah, an artsy kind of deal ~

Aaaaaah, so you can make one event listener, but toggle by the name of the target?  Brilliant!  Could I do that with y position/getChildIndex?  I don't see why not, right?  Just so I don't have to name all the buttons..  I'm utilizing getPixel in the palette anyway but yeah, I'm using vector buttons.  This gives me a lot to consider, thank you.  I'll mark this as answered if no objections are brought up haha...

kdmemory
kdmemory
Inspiring
February 7, 2019

Hi dolldivine

is this an academic ivory tower question? Or do have a real project for which you need to know this?

Let's talk numbers. How many panels with how many buttons in each panel are we talking about?

Also it would be helpful to know what platform you are targetting ?

  • Flash Player / AS3,
  • AIR for Desktop / AS3
  • AIR for Android or iOS / AS3
  • HTML5 Canvas / Javascript

Please provide some more info and narrow the whole thing down.

Klaus

dolldivine
dolldivineAuthor
Inspiring
February 7, 2019

Hi Klaus,

Thanks!  Question is based in reality for sure

More than one project even.

AS3 for Flash Player *and* Android *and* iOS.  The biggest concern for memory seems to be AIR for Android, because phones are slower than desktop, and Android users don't upgrade devices as often as Apple. (right?)

Something like 10-15 panels

On the higher end in mobile layout.

Each panel might have anywhere from 5-20 item buttons, and an additional ~70 buttons per colour palette.  Possibly as many as 3 colour palettes per panel.  So in theory as many as 200+ buttons per panel.

Quite asset heavy too, with a lot of vector graphics.  I've already learned the hard way to keep filters and effects to an absolute minimum.

kdmemory
kdmemoryCorrect answer
Inspiring
February 8, 2019

Hi Dolldivine,

I wonder what your project will be like. is it some kind of paint program? With so many colour palettes?

With the new information going back to your original question. Is it better to create each panel in a seperate frame or having them all in one frame and working with visible = true/false or similar means (like animating panels out of sight).

I would definately say it is better to stay in one frame. I'm not so deep into technical memory management matters, but I'm convinced that spreading it over multiple frames doesn't help. It won't be like when the playhead jumps from i.e. frame 1 to frame 2, that everything in frame 1 can be discarded from memory. And the permanent need of gotoAndStop() when interacting with panels won't help either.

     Now about the eventListeners. Considering your numbers, you could end up with 2000+ interactive touchspots. I presume your are not seriously contemplating to provide each one of them with an eventListener, are you? Anyway because of opening vs closing panels (visible or any other method) you will have a hierachy of objects like your panels are movieClips containing all other stuff like touchspots and colour palettes).  What I would do is give each panel one eventListener and one eventFunction and code something like

panel1.addEventListener(MouseEvent.CLICK, clickHandlerPanel1);
function clickHandlerPanel1(evt: MouseEvent) {
    switch (evt.target.name) {
        case "spot1":
            bringOnPanel("panel1");
            break;
        case "spot2":
            //do something when spot2 is pressed
            break;
        case "spot3":
            //do something when spot3 is pressed
            break;
            //.. and so forth
    }
}

This way it would be enough to have 10 - 15 eventHandlers. Easier to manage like removeEventListener(). And we utilize evt.target to detect which touchspot in particular has been pressed.

  • evt.currentTarget = woudl be in our scenario panel1, the object with the attached eventListener
  • evt.target = the object that actually received the click

     Now about your colour palettes. It seems that this section costitutes the largest group of interactive touchspots. "..additional ~70 buttons per colour palette.  Possibly as many as 3 colour palettes per panel." - If this is about some kind of colour picking like using color swatches, you could instead of having so many vector swatch buttons design bitmap colour swatches and utilize the bitmapData class with methods like getPixel() or getPixel32() to detect and set colour values.

I hope this helps a bit

Klaus

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices