An open-source, web-based viewer for zoomable images, implemented in pure JavaScript.
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.
@aeschylus Interesting... do you know what's calling it?
"The call is coming from inside the house!"
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
The "anonymous function" at the bottom of the call stack is scheduleUpdate
function scheduleUpdate( viewer, updateFunc ){
return $.requestAnimationFrame( function(){
updateFunc( viewer );
} );
}
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)
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)
Hm.
That
raiseEvent call is probably the update-viewport event... the anonymous function above it is presumably mirador's event handler for that event
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!).
Indeed indeed!
Besides that, how are things going in Mirador/iiifManifestLayouts-land?
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.
Cool :)
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.
Yeah, and tricky to interface that with OSD which doesn't think that way anyway
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.
Fair enough... well, it was worth trying!
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.
Excellent... sounds slick. :)
Glad to hear it's coming along!