Highlighted

Which UI setup would use less memory?

Contributor ,
Feb 07, 2019

Copy link to clipboard

Copied

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...

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

Views

337

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Which UI setup would use less memory?

Contributor ,
Feb 07, 2019

Copy link to clipboard

Copied

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...

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

Views

338

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Feb 07, 2019 0
Advocate ,
Feb 07, 2019

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 07, 2019 0
Contributor ,
Feb 07, 2019

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 07, 2019 0
Advocate ,
Feb 08, 2019

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 08, 2019 1
Contributor ,
Feb 11, 2019

Copy link to clipboard

Copied

I'm making this happen.

Switching to target instead of currentTarget has been tricky since a lot of the menu items are very nested movieclips.  But I selected all the palette MC's and set them to "export as bitmap" so now using "target" treats the whole swatch as one thing, instead of yielding various results depending on which part of the colour button was clicked.  I've already reduced the # of listeners significantly!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 11, 2019 1
Contributor ,
Feb 08, 2019

Copy link to clipboard

Copied

Wow, thanks! 😮

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...

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 08, 2019 0