These are chat archives for openseadragon/openseadragon

27th
Oct 2014
Christian Kütbach
@ckuetbach
Oct 27 2014 15:34
Hi there, I have some trouble with OpenSeaDragon (1.1.1): I call OpenSeadragonInstance.destroy(), but the Animationframes are still being requested (any browser). this will lead to higher CPU consumption. Any Ideas?
Ian Gilman
@iangilman
Oct 27 2014 16:52
@ckuetbach :-(
Nothing off the top of my head... you should file an issue.
If you're up for helping us debug it, I can point you in the right direction.
Ian Gilman
@iangilman
Oct 27 2014 17:47
@ckuetbach looking at the code it seems like it should work... https://github.com/openseadragon/openseadragon/blob/master/src/viewer.js#L2660 doesn't fire a new update if the viewer.source is falsey, and https://github.com/openseadragon/openseadragon/blob/master/src/viewer.js#L550 sets it to null on close, which is called by destroy.
Do you happen to know which of the animation frame requests in the system is being called?
Christian Kütbach
@ckuetbach
Oct 27 2014 18:56
I will debug it tomorrow, when I am back at office.
viewer.source never gets falsy (as I rememver)
If I open http://openseadragon.github.io/ and open the debug tools, I can see requestAnimationframes, even if the canvas don't seem to be dirty. (Chrome, I think also in other browser)
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:01
ckuetbach: this is necessary to detect if the viewer container has been resized
oops, no it has been updated and now also use animationFrame :(
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:12
Christian Kütbach
@ckuetbach
Oct 27 2014 19:33
Sorry, I don't get the link between requestAnimationframe and css element queries
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:36
openseadragon needs to detect if the viewer's size changes in order to redraw its content, unfortunately, there is no JS event for that. A common workaround is to just check if the size changed between 2 animation frames.
Christian Kütbach
@ckuetbach
Oct 27 2014 19:37
So I see the request to animationframe just to ensure the size did not change?
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:38
yup
Christian Kütbach
@ckuetbach
Oct 27 2014 19:38
these requests seems also to be made, if destroy() was called.
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:38
that should be disabled when the viewer is destroyed though
Christian Kütbach
@ckuetbach
Oct 27 2014 19:39
In my case I create the viewer more than once (exactly one per time, but for every document, wich should be visualized once)
after displaying 50 Images (or something) I get a high CPU usage. Maybe there still live "destroyed" instances in the DOM?
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:42
yeah that is possible. Any reason to destroy/recreate instead of opening/closing the same instance?
Christian Kütbach
@ckuetbach
Oct 27 2014 19:43
I got some problems reusing the instance. But I will try it tomorrow at work
I have some kind of slow testing maschine... the Internet Explorer uses up to 60% of the CPU :) So I shpuld finde a way to fix it
If I remember correct my problems where because I remove the div element which is containing the viewer canvas from the DOM and I had trouble to open the viewer again
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:48
ok, that makes sense.
a potential dirty workaround is to make the div element containing the viewer invisible instead of removing it from the DOM
Christian Kütbach
@ckuetbach
Oct 27 2014 19:53
I am using GWT. Removing the views from the DOM is a common use case there (GWT is a Java to JavaScript X-compiler). Not needed elements will automaticly be removed from DOM. But maybe I can make it invisible and move it to another place ...
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:54
ok, in any case better just fix OSD if there is a bug :)
Christian Kütbach
@ckuetbach
Oct 27 2014 19:55
Is there a way to stop the resizehandler? I have a Window Resize Handler. Only when the windows is resized, the viewer needs an update (there will be no resizing of the viewer, if the windows stays the same size)
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:56
unfortunately no
Christian Kütbach
@ckuetbach
Oct 27 2014 19:56
I will debug deeper tomorrow (It is 9PM here, should not think about the work now)
Thanks a lot, for your help.
Antoine Vandecreme
@avandecreme
Oct 27 2014 19:57
no problem
Christian Kütbach
@ckuetbach
Oct 27 2014 20:03
Just one more question: updateMulti() is called in the requestAnimationframe() does this just check for the sizes?
Antoine Vandecreme
@avandecreme
Oct 27 2014 20:04
nope, it also updates the viewer (taking into account the current pan and zoom)
Christian Kütbach
@ckuetbach
Oct 27 2014 20:06
Well... this method is called in my case
Ian Gilman
@iangilman
Oct 27 2014 22:41
The viewer already has an autoResize option you can turn off, but looks like we don't actually stop the requestAnimationFrame sequence if it's turned off. That would be a good thing to fix. Then you could detect the resize yourself and force a redraw then.
@ckuetbach You shouldn't be getting updateMulti if all of your viewer.sources are falsey, so somehow the destroy isn't getting called on one of them or something.