Use /api/assetImage for imageUrl
In this change, we start using our new API endpoint for movie image URLs, instead of the Classic DTI image. This should make the little fade-in phase for certain movies a little bit less jarring (the part where we preload the image before the movie loads), though I suppose that won't necessarily load as fast until it gets into the cache the first time lol. (A good reason to maybe put a more long-lived cache like Fastly in front of this stuff long-term?) Not doing it for the smaller image sizes yet, I'm a bit worried that I don't 100% know how to teach /api/assetImage to resize without tipping over the function limit… …oh! I should have the webpage render at different sizes! Yeah that's a great idea lol
This commit is contained in:
parent
adf70dc25f
commit
7719ab8c07
1 changed files with 17 additions and 0 deletions
|
@ -204,7 +204,24 @@ const resolvers = {
|
|||
if (format === "lod" && !jsAssetUrl && pngAssetUrl) {
|
||||
return pngAssetUrl.toString();
|
||||
}
|
||||
|
||||
// Or, if this is a movie, we can generate the PNG ourselves.
|
||||
// TODO: Support this for smaller image sizes, too.
|
||||
if (format === "lod" && jsAssetUrl) {
|
||||
const httpsJsAssetUrl = jsAssetUrl
|
||||
.toString()
|
||||
.replace(/^http:\/\//, "https://");
|
||||
return (
|
||||
`https://impress-2020.openneo.net/api/assetImage` +
|
||||
`?libraryUrl=${encodeURIComponent(httpsJsAssetUrl)}`
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
// Otherwise, fall back to the Classic DTI image storage, which is
|
||||
// generated from the SWFs (or sometimes manually overridden). It's less
|
||||
// accurate, but well-tested to generally work okay, and it's the only
|
||||
// image we have for assets not yet converted to HTML5.
|
||||
|
||||
// If there's no image, return null. (In the development db, which isn't
|
||||
// aware which assets we have images for on the DTI CDN, assume we _do_
|
||||
|
|
Loading…
Reference in a new issue