[SOLVED] EOS Memory Leak

[lolol2]

I changed all my goto actions to pages.goto(...) evals

I played a bit around with that too, but could never seen any difference between them.
When you call a range of pages with an wildcard name, the memory will gets overloaded.

Maybe it's possible to reduce this when you only use one page with if/else statements to load different pictures instead of using a wildcard range... maybe I will try this soon.

[fapnip]

Maybe it's possible to reduce this when you only use one page with if/else statements to load different pictures instead of using a wildcard range... maybe I will try this soon.

What I do to hopefully work around the memory leak issue:
- var pageStack = [] (an array of page names)
- "callPage(pageId)" function that will pageStack.push(pages.getCurrentPageId()), then pages.goto(pageId).
- "returnPage()" function that pages.goto(pageStack.pop()).
- "curentImage" variable to hold current image
- put all my images in individual pages, like "image-x-y-x, that has only a single image action (do not add more than one -- all of them will be pre-loaded over and over again, even if "IF" actions should isolate them to one) and a returnPage() eval". (Where x, y, and z are simply related to your use case. Perhaps you only one or two arguments... Like, gameLevel, gameRound, etc.)
- "loadImage(x, y, z) function that generates an imagePageName var for the images based on the arguments passed, checks if curentImage is that page name, and if not, set curentImage = imagePageName , and callPage(imagePageName)"

I don't use EOS page wildcards. Instead, I do any randomization in JavaScript, then use my loadImage function(s) to load images in an eval that is the very first action of any page that's loading an image. (Any actions after the loadImage eval may not be called until we return from the image load (Note: Script after the loadImage call in the SAME eval MAY continue to be executed, so loadImage should be the last expression in the eval action), and any actions/script before the loadImage call could be re-executed on return from the loadImage call.)

[fapnip]

Here's a simplified example of what I'm doing to allow a single core page select and display a given image:
Load Image Example

(Here's the JSON)

The one thing I'm not doing is pre-loading any images, so if your connection to milovana is slow, you can get stuck waiting for images from time to time. You could emulate pre-loading by wrapping the image in the image pages in an IF (!PRELOAD) action, then set a global PRELOAD var to true, iterate through the images/pages you want to pre-load, then set PRELOAD = false. Even though the image wouldn't be displayed because the if action wouldn't hit, EOS will download the image.

[seraph0x]

Just pushed an update with a different style of preloader - please let me know if this fixes the issue for you.

[lolol2]

Now it works fine! The tab will grow to around ~1,2GB memory usage and then starting to clear some space and the tease won't break.
THANK YOU!!!