Swap from dummy to actual tile source automatically

[iangilman]

I propose the best way to handle this swap is to pay attention to zoom and pan events and detect which canvases become large enough in the viewer to warrant the swap.

Noting this here is a follow-up to #40. /cc @nein09

[aeschylus]

I don't think I commented on this earlier, but this seems like a good and more robust way to handle this problem. It will also allow us to turn the thumbnail overlays on and off more easily, since we can use html images for them, but the dummies will still be available underneath. This will prevent crossover of the borders and OSD images.

[aeschylus]

The logic on the last PR (#112) for legacy tilesources was correct, but it looks like the requests for thumbnails are asking for /full/full/. This is seriously affecting performance. Please have a look at how this was done before (the legacy thumb requests have a size no more than twice their thumbnail size).

var dummy = {
    type: 'legacy-image-pyramid',
                                            levels: [{
                                                url: canvasData.thumbService + '/full/' + Math.ceil(d.canvas.width * 2) + ',/0/default.jpg',
                                                width: canvasData.width,
                                                height: canvasData.height
                                            }]
                                        };

I will merge a fix for this today, but just be on the lookout (for instance when working on semantic zoom ( #115 ).

[nein09]

@aeschylus Did I address this correctly in https://github.com/sul-dlss/iiifManifestLayouts/pull/116 ?

[aeschylus]

Yes for the case where the URL is a IIIF base, although I think that is a rare case.

The problem with the Osborn object is that it complies with the spec too well! Along these lines, #116 brings up an interesting thing I left out of my briefs/specs: content resources can have a thumbnail field. So that should be taken first as the static thumbnail before any others. See "thumbnail" in descriptive properties in the iiif spec. So that's one more check to add I suppose.

That doesn't help the full/full problem though. I think if there is no thumbnail property on the resource, and we see that the @id is a valid url, we need to also check if it is a iiif resource and if it is, construct our own thumbnail using the stripped url. There isn't really anything we can do in the case where there is no thumbnail, no service, the @id is not to a iiif resource, and the returned image just happens to be 1000000 pixels across, sadly. I guess we could potentially throttle the requests for those urls and write the image to a canvas element and derive a tiny image that we cache somewhere as a datauri, then request the next one, but that is a hyper-optimisation for another day!

The case where we have no thumbnail property and the @id is a iiif url to full/full will be fairly common, so we should trim the url and use that.

There is another potential issue with using default.jpg versus native.jpg (if the @id is a iiif base, thendefault` might be wrong, since we haven't requested the info.json to get the version, which is what we're trying to avoid), but we can cover that another time.

For now add a case for the iiif urls in the @id that trims them and constructs an efficient url like the current #116. I'll merge that today.