Closed Ottodix closed 6 years ago
Well, your panel uses up 1GB worth of memory :\
If you really want to store a lot of images you can increase the heap limit through advanced settings: Preferences
>Advanced
>Tools
>Spider Monkey Panel
>Maximum heap size
.
PS: IMO, storing such amount of art images in memory is overkill =)
PPS: Maximum heap size
is the only value that is safe to change in Advanced
settings, I don't recommend changing anything else, since it might impact your panel performance hard in really unexpected ways.
PPPS: The limit is per process, not per panel, so adjust accordingly.
Thanks! On this code which isn't optimized at all, yes, it uses a lot of memory. But on my real code which is a lot more complicate, it load a smaller version of the covers little by little without freezing foobar, and it uses around 150Mo (for 3000+ albums). On my computer, the increase of ram is completely okey, and i can navigate between albums without any loading time for the covers. I increased this Maximum heap size, now i don't have "out of memory" errors, but the images are lost between panels, i used to send this array of covers from one panel to another using on_notify_data and a deep clone of the received object, but the resulting images are now... corrupt ? I don't know exactly, but gr.DrawImage() now crash with them (DrawImage failed: Object is not of valid type). It's new from this 1.04 version, with the very first version of spider monkey panel, it is working.
So for the moment, i can't use this new version if i want to keep this cover cache :/
it uses around 150Mo
It actually uses MUCH more. Images are not stored in your usual memory (i.e. the one that you can see via Task Manager), but rather kernel memory which is not counted towards fb2k memory usage (but counts towards total RAM usage). E.g. when your panel OOM'd the task manager might've displayed smth around 200mb usage in fb2k, but total RAM usage would've been 1.2Gb.
i used to send this array of covers from one panel to another using on_notify_data
You can't do this on SMP, this is a JS engine limitation: see doc for details. You'll have to move image the acquisition code to the panel in which you want to use said image.
On another note: one of the features that I'm working on might enable the deep clone
of some native objects (like GdiImage). So your scenario might be possible in the future.
It's true that i was looking just at the amount of RAM used by foobar, i just tried looking at the RAM used by the computer instead of just foobar, and the increase isn't so big when i start foobar, it seems to be similar, a little bit more but ok (50Mo more). I don't cache the full covers, i cache only small jpeg versions
Then i'll keep the first version of SMP. Anyway, it's true that my code is quite specific to my configuration, i guess there isn't much people trying to build a cover cache across all their panels like me : )
Then i'll keep the first version of SMP
Well, native object transfer via NotifyOthers
was never possible on SMP, so using first version won't help in your case :\
And I strongly advise against using the first version, since it has a lot of bugs that were fixed in the latest version: CHANGELOG
It is working, i use NotifyOthers() in order to send an array of GdiImage(), and i receive the array with on_notify_data(name,info) using images = iterationCopy(info)
Where iterationCopy is this function
function iterationCopy(src) { let target = {}; for (let prop in src) { if (src.hasOwnProperty(prop)) { target[prop] = src[prop]; } } return target; }
Why did it break with the new version, or why did it work with the first one, i don't know, but it work :)
So your scenario might be possible in the future.
Done! Added constructors in the latest version, so your scenario is possible now (you still have to increase heap limit via advanced settings though):
// performs a deep-copy of `image_from_notify`, so it is available even outside of `on_notify_data` callback
let copy_img = new GdiBitmap(image_from_notify);
Hi,
With the lastest release, a panel using too much memory seems to crash. I used to do a cover cache, i can't do it anymore with the lastest release. Here is a example of code which always crash on my setup, it create a array containing the covers of the 2000 first tracks, grabbed with utils.GetAlbumArtV2:
Error message:
Error: Spider Monkey Panel v1.0.4 ({9B3A2903-6468-463C-8579-15BBC1C4738F}) Out of memory: 1020262025/1000000000 bytes