memory hog during rebind/set about imagemapster

[ryanscode]

edit: if I dont use rebind, i have to mapster.set(false

[jamietre]

Based on what you are describing, I am guessing that you are calling the "set" effect dozens of times for each slide. Because it takes ImageMapster a lot longer (in millisecond terms) to draw the map than it takes to move a mouse a few pixels, dozens of "slide" events will be queued, and you'll be calling it over and over again, and it could take a long time (like 5 or 10 seconds) for the browser to catch up.

The memory consumption probably has nothing to do with imagemapster per se but just as a consequence of a calling heavy graphics manipulation code a lot of times in sequence, and it just takes garbage collection a few seconds to catch up.

I think your basic problem is that there's no limit on how often you call "set." It might be getting called 50 times for a split-second slide, but there's no way the browser would ever be fast enough to redraw a complex image 50 times in a second (without using webGL or something, anyway). You should avoid calling set when the browser can't keep up with the rendering effect.

The solution is just don't call it every single time the event fires. Instead, use "setTimeout" to start it asynchronously only if there's not a set operation active already. The reason for using a timer is because it starts the operation asynchronously. If you did not do this, then the slide events would be queued and you couldn't prevent it from being called each time the event fired.

var effectActive = false;

function sliderSlide() {
    if (!effectActive) {
        effectActive = true;
        window.setTimeout(function() {
            // set options as needed first
            $('img').mapster('set',true,keys);
            effectActive = false;
        },50);    // 50 ms is usually the smallest time that will work for setTimeout 
}

The only problem you might have as coded, is that when the slider stops, it may not end up matching exactly the last position of the slider since it could have been in the middle of a previous effect when the slider stopped. So just call the "set" code from the slider's stop or slide finished event also.

[ryanscode]

Firstly, thanks for the awesomely quick and detailed response!..

you are calling the "set" effect dozens of times for each slide

No, I isolated it first and call it just once. I'm forseeing trouble when I integrate it with the slider.
The memory increase is quite real and correlates with the 'set's.
Thanks for your code, that'll be perfect once I integrate.

Since I have to effect a change to the view I seem to need to call (set, false) before (set, true). Is the following correct?

         //'areas' is a csv of all keys
         img.mapster('set',false,areas); //first clear... 
         img.mapster('set',true,areas); // ..then set
         
        // (set, true) doesn't seem to work if I call it a second time without calling (set, false)

[jamietre]

Yes, you do need to unset first - this could be part of the problem. Because imagemapster uses only one canvas for all selections, to unset, it must effectively redraw the entire canvas. (That is, an unset is really a clear followed by a redraw of the areas still unset). This code is probably not optimized for "clearing" all the selections. I will have to take a look at it but I bet the slowdown is during the unset, and not the set.

edit - actually - that first paragraph may not be true. It depends what version you are using. The current dev code no longer checks the state before rendering something. If you are using the dev code you don't need to unset first - and maybe this will resolve the issue.

I also create a temporary canvas during this to prevent flickering (e.g. to unset an area, I redraw everything in the new state, then show the new canvas, then hide/destroy the old one). This would also consume more memory.

I honestly can't think of anything in imagemapster itself that would use that much memory, though, except for something like a map with thousands of areas. So I am assuming it has to do with overhead of creating & destroying canvases and gets GC'd.

In any event I can take a look at the "unset" code - perhaps a "clear" method is in order which would circumvent all the code that is only important when areas remain selected. That should be pretty easy to add.

[ryanscode]

Strangely...
I've been working with FF9 all this while. I just tried the same code in IE8 and there is no 'slowness' or memory usage increase... and somehow the fillOpacity and fillColor is not just being honored.. strange

[jamietre]

Can you set up something on jsfiddle so I can see what you're dealing with?

[ryanscode]

will do.. but I just downloaded the dev version. It rocks! Much smoother. Thanks so much. Will keep you posted