Commit graph

7 commits

Author SHA1 Message Date
de974a365b fix bug with items with %20 in movie clip URL
"Beautiful Green Painting Background" wasn't loading! https://impress-2020.openneo.net/items/75594

```Error building movie clips Error: Expected JS movie library http://images.neopets.com/cp/items/data/000/000/491/491273_31368b3745/491273_2_HTML5%20Canvas.js to contain a constructor named _491273_2_HTML5%20Canvas, but it did not: ssMetadata,Bitmap3,Bitmap5,CachedTexturedBitmap_4183,CachedTexturedBitmap_4184,CachedTexturedBitmap_4185,CachedTexturedBitmap_4186,CachedTexturedBitmap_4187,Symbol20,Symbol8,Symbol4,Symbol7,Symbol2,Symbol1,Symbol9,Symbol2copy,Symbol2_1,_491273_2_HTML5Canvas,properties,Stage```

We already had code to strip out spaces, but not encoded spaces like %20. Now, we decode the URL first, so that space-stripping will work even if it was encoded.
2020-10-28 00:29:32 -07:00
49d3b3685d add CORS for movie clip asset loading
I think the issue with the Spring Topiary Garden Background is that EaselJS is trying to do intermediate canvas reads in order to apply computed filters, but loading from our asset proxy counts as tainted data.

Here's the traceback I got in Chrome for it:
```
Error building movie clips DOMException: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': The canvas has been tainted by cross-origin data.
    at a.b._applyFilters (https://code.createjs.com/1.0.0/easeljs.min.js:15:12029)
    at a.b._drawToCache (https://code.createjs.com/1.0.0/easeljs.min.js:15:11806)
    at a.b.update (https://code.createjs.com/1.0.0/easeljs.min.js:15:8638)
    at a.b.define (https://code.createjs.com/1.0.0/easeljs.min.js:15:8148)
    at lib.Flowerfront.b.cache (https://code.createjs.com/1.0.0/easeljs.min.js:13:3361)
    at new lib.Bg (https://images.neopets-asset-proxy.openneo.net/cp/items/data/000/000/441/441520_f4a43d48bf/441520HTML5.js:4266:16)
    at new lib._441520HTML5 (https://images.neopets-asset-proxy.openneo.net/cp/items/data/000/000/441/441520_f4a43d48bf/441520HTML5.js:5291:18)
    at x (https://impress-2020.openneo.net/static/js/11.3a356cfe.chunk.js:1:12286)
    at https://impress-2020.openneo.net/static/js/11.3a356cfe.chunk.js:1:17768
    at Array.map (<anonymous>)
```

To try to fix this, I've updated our Fastly config to version 8, which should accept CORS requests from https://impress-2020.openneo.net. And here, I've updated the movie clip assets to be requested CORS-style, so that the Origin header will actually be set.

It's hard to test this without just, pushing it to prod. I've confirmed in isolation that setting the `Origin` header in the request yields the expected `Access-Control-Allow-Origin` response header, and that the `Vary` header is set correctly too. But, end-to-end, I don't really have great mockability here—maybe with a good proxy setup I could do it? But nah, let's just push and find out!
2020-10-23 00:20:50 -07:00
d99f5d7ac8 oops, fix missing react hook dep! 2020-10-22 15:46:22 -07:00
9a36a6ec69 don't advance movies by a frame when resizing 2020-10-10 04:51:53 -07:00
afe9fcf392 fade in for movie layers, too
gosh I hope I didn't break everything 😅
2020-10-10 03:46:23 -07:00
ad43f58a07 fix Download button to use better caching
So I broke the Download button when we switched to impress-2020.openneo.net, and I forgot to update the Amazon S3 config.

But in addition to that, I'm making some code changes here, to make downloads faster: we now use exactly the same URL and crossOrigin configuration between the <img> tag on the page, and the image that the Download button requests, which ensures that it can use the cached copy instead of loading new stuff. (There were two main cases: 1. it always loaded the PNGs instead of the SVG, which doesn't matter for quality if we're rendering a 600x600 bitmap anyway, but is good caching, and 2. send `crossOrigin` on the <img> tag, which isn't necessary there, but is necessary for Download, and having them match means we can use the cached copy.)
2020-10-10 01:21:47 -07:00
1875931a48 simplify canvas code, just use separate elements
Previously I tried to be clever and pre-optimize by putting all the layers onto one canvas… I think this probably helped by batching their paints, but it made fades less smooth by not taking advantage of native CSS transitions, and it made us dip into JS way more often than necessary.

Here, I take the simpler approach: just layers of <img> and <canvas> tags, with each animated layer on its own canvas, and letting the browser handle transitions and compositing, and separate `setInterval` timers to manage their framerates.

I have a suspicion that batching the paints could help performance more, but honestly, maybe that batching is already happening somehow, because things look pretty great on my big-screen stress test now; and so if it _is_ relevant, I want to wait and see after testing on low-power devices.
2020-10-08 04:13:47 -07:00