These are chat archives for openseadragon/openseadragon

16th
Aug 2016
aeschylus
@aeschylus
Aug 16 2016 18:04
I'm getting a weird error in the most recent OSD release: [Viewport.viewportToImageZoom] is not accurate with multi-image.
What's strange is, it only seems to be a problem when embedded in another application.
It works fine in some other context.
Apparently this happens when trying to add a tilesource.
The call to viewportToImageZoom is coming from inside osd.
Ian Gilman
@iangilman
Aug 16 2016 18:14
@aeschylus Interesting... do you know what's calling it?
"The call is coming from inside the house!"
aeschylus
@aeschylus
Aug 16 2016 18:14
haha.
mirador.js:39983 [Viewport.viewportToImageZoom] is not accurate with multi-image.viewportToImageZoom @ mirador.js:39983resize @ mirador.js:51821_thisResize @ mirador.js:51259(anonymous function) @ mirador.js:24355raiseEvent @ mirador.js:24377drawWorld @ mirador.js:31357updateOnce @ mirador.js:31298updateMulti @ mirador.js:31221(anonymous function) @ mirador.js:30527
Screen Shot 2016-08-16 at 11.15.12.png
The "anonymous function" at the bottom of the call stack is scheduleUpdate
function scheduleUpdate( viewer, updateFunc ){
return $.requestAnimationFrame( function(){
updateFunc( viewer );
} );
}
So it's happening in the draw loop, hence why it's coming from the inside.
What's strange is that this error does not occur when I run it outside of Mirador.
(in the dreaded iiifManifestLayouts)
Ian Gilman
@iangilman
Aug 16 2016 18:18
Looks like the call is actually coming from resize which doesn't look like it's part of OSD
Is that a mirador function?
It's true that viewportToImageZoom isn't accurate with multi-image... you should instead pick the image you care about from the world and call its viewportToImageZoom
e.g. viewer.world.getItemAt(0).viewportToImageZoom(zoom)
aeschylus
@aeschylus
Aug 16 2016 18:21
Hm.
Ian Gilman
@iangilman
Aug 16 2016 18:22
That raiseEvent call is probably the update-viewport event... the anonymous function above it is presumably mirador's event handler for that event
aeschylus
@aeschylus
Aug 16 2016 18:23
Ah, I found it. Yeah, that resize function it attempting to resize the viewport directly (some new annotation code I'm not familiar with yet - it's hard to keep track of things with multiple people contributing to an opensource project!).
Ian Gilman
@iangilman
Aug 16 2016 18:23
Indeed indeed!
Besides that, how are things going in Mirador/iiifManifestLayouts-land?
aeschylus
@aeschylus
Aug 16 2016 18:24
Thanks for the help. We're translating everything over the IIIFML so we can get canvas coordinates, so it looks like this is the first instance of needing to rewrite all the coordinate queries in annotation stuff.
It's going alright.
We're "nearing" a release.
IIIFML is completely refactored
and everything is events based now.
Ian Gilman
@iangilman
Aug 16 2016 18:25
Cool :)
aeschylus
@aeschylus
Aug 16 2016 18:25
I abandoned (for the most part) the state thing. Without some kind of react-ish view diffing, it's basically impossible to keep track of what's going on.
Ian Gilman
@iangilman
Aug 16 2016 18:26
Yeah, and tricky to interface that with OSD which doesn't think that way anyway
aeschylus
@aeschylus
Aug 16 2016 18:26
d3 sort of handles it, but there are too many directionally conditional transitions to write a single function describing the state as a given moment without creating a game loop.
Yeah.
Ian Gilman
@iangilman
Aug 16 2016 18:26
Fair enough... well, it was worth trying!
aeschylus
@aeschylus
Aug 16 2016 18:27
I basically have a little "server" object representing each canvas. When it gets updated, it fires an event, and an osd wrapper acts as a subscriber and calls internal functions as a result.
Seems to be working pretty well. OSD is working great. I'll send an announcement here when it's all wrapped up.
Ian Gilman
@iangilman
Aug 16 2016 18:29
Excellent... sounds slick. :)
Glad to hear it's coming along!