2020-04-23 13:31:39 -07:00
|
|
|
import React from "react";
|
2020-09-13 04:12:14 -07:00
|
|
|
import { Box, DarkMode, Flex, Text } from "@chakra-ui/core";
|
2020-07-20 21:32:42 -07:00
|
|
|
import { WarningIcon } from "@chakra-ui/icons";
|
2020-10-10 03:46:23 -07:00
|
|
|
import { css } from "emotion";
|
2020-09-21 18:50:27 -07:00
|
|
|
import { CSSTransition, TransitionGroup } from "react-transition-group";
|
2020-04-24 19:16:24 -07:00
|
|
|
|
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
|
|
|
import OutfitMovieLayer, {
|
|
|
|
buildMovieClip,
|
|
|
|
hasAnimations,
|
|
|
|
loadMovieLibrary,
|
2020-09-22 01:44:24 -07:00
|
|
|
useEaselDependenciesLoader,
|
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
|
|
|
} from "./OutfitMovieLayer";
|
2020-07-22 21:29:57 -07:00
|
|
|
import HangerSpinner from "./HangerSpinner";
|
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:19:59 -07:00
|
|
|
import { loadImage, safeImageUrl, useLocalStorage } from "../util";
|
2020-05-02 13:40:37 -07:00
|
|
|
import useOutfitAppearance from "./useOutfitAppearance";
|
2020-04-24 23:13:28 -07:00
|
|
|
|
2020-05-02 13:40:37 -07:00
|
|
|
/**
|
2020-07-22 21:29:57 -07:00
|
|
|
* OutfitPreview is for rendering a full outfit! It accepts outfit data,
|
|
|
|
* fetches the appearance data for it, and preloads and renders the layers
|
|
|
|
* together.
|
|
|
|
*
|
2020-07-22 22:07:45 -07:00
|
|
|
* If the species/color/pose fields are null and a `placeholder` node is
|
|
|
|
* provided instead, we'll render the placeholder. And then, once those props
|
|
|
|
* become non-null, we'll keep showing the placeholder below the loading
|
|
|
|
* overlay until loading completes. (We use this on the homepage to show the
|
|
|
|
* beach splash until outfit data arrives!)
|
|
|
|
*
|
2020-07-22 21:29:57 -07:00
|
|
|
* TODO: There's some duplicate work happening in useOutfitAppearance and
|
|
|
|
* useOutfitState both getting appearance data on first load...
|
2020-05-02 13:40:37 -07:00
|
|
|
*/
|
2020-07-22 22:15:07 -07:00
|
|
|
function OutfitPreview({
|
|
|
|
speciesId,
|
|
|
|
colorId,
|
|
|
|
pose,
|
|
|
|
wornItemIds,
|
2020-09-13 04:12:14 -07:00
|
|
|
appearanceId = null,
|
2020-09-21 02:43:58 -07:00
|
|
|
isLoading = false,
|
2020-07-22 22:15:07 -07:00
|
|
|
placeholder,
|
2020-09-13 04:12:14 -07:00
|
|
|
loadingDelayMs,
|
|
|
|
spinnerVariant,
|
2020-09-24 06:13:27 -07:00
|
|
|
onChangeHasAnimations = null,
|
2020-07-22 22:15:07 -07:00
|
|
|
}) {
|
2020-07-22 21:29:57 -07:00
|
|
|
const { loading, error, visibleLayers } = useOutfitAppearance({
|
|
|
|
speciesId,
|
|
|
|
colorId,
|
|
|
|
pose,
|
2020-08-28 22:58:39 -07:00
|
|
|
appearanceId,
|
2020-07-22 21:29:57 -07:00
|
|
|
wornItemIds,
|
|
|
|
});
|
2020-04-25 07:22:03 -07:00
|
|
|
|
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
|
|
|
const {
|
|
|
|
loading: loading2,
|
|
|
|
error: error2,
|
|
|
|
loadedLayers,
|
|
|
|
layersHaveAnimations,
|
|
|
|
} = usePreloadLayers(visibleLayers);
|
|
|
|
|
|
|
|
const [isPaused] = useLocalStorage("DTIOutfitIsPaused", true);
|
|
|
|
|
|
|
|
React.useEffect(() => {
|
2020-10-08 04:20:23 -07:00
|
|
|
if (onChangeHasAnimations) {
|
|
|
|
onChangeHasAnimations(layersHaveAnimations);
|
|
|
|
}
|
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
|
|
|
}, [layersHaveAnimations, onChangeHasAnimations]);
|
2020-06-05 23:56:42 -07:00
|
|
|
|
2020-07-22 21:29:57 -07:00
|
|
|
if (error || error2) {
|
2020-04-23 13:31:39 -07:00
|
|
|
return (
|
|
|
|
<FullScreenCenter>
|
2020-09-10 03:06:44 -07:00
|
|
|
<Text color="green.50" d="flex" alignItems="center">
|
2020-07-20 21:32:42 -07:00
|
|
|
<WarningIcon />
|
2020-04-23 13:31:39 -07:00
|
|
|
<Box width={2} />
|
|
|
|
Could not load preview. Try again?
|
|
|
|
</Text>
|
|
|
|
</FullScreenCenter>
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2020-05-02 22:59:30 -07:00
|
|
|
return (
|
2020-09-13 04:12:14 -07:00
|
|
|
<OutfitLayers
|
2020-09-21 02:43:58 -07:00
|
|
|
loading={isLoading || loading || loading2}
|
2020-09-13 04:12:14 -07:00
|
|
|
visibleLayers={loadedLayers}
|
|
|
|
placeholder={placeholder}
|
|
|
|
loadingDelayMs={loadingDelayMs}
|
|
|
|
spinnerVariant={spinnerVariant}
|
2020-09-24 06:13:27 -07:00
|
|
|
onChangeHasAnimations={onChangeHasAnimations}
|
2020-09-21 18:50:27 -07:00
|
|
|
doTransitions
|
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
|
|
|
isPaused={isPaused}
|
2020-09-13 04:12:14 -07:00
|
|
|
/>
|
2020-05-02 22:59:30 -07:00
|
|
|
);
|
2020-05-02 21:04:54 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* OutfitLayers is the raw UI component for rendering outfit layers. It's
|
|
|
|
* used both in the main outfit preview, and in other minor UIs!
|
|
|
|
*/
|
2020-07-22 22:07:45 -07:00
|
|
|
export function OutfitLayers({
|
|
|
|
loading,
|
|
|
|
visibleLayers,
|
|
|
|
placeholder,
|
2020-09-13 04:12:14 -07:00
|
|
|
loadingDelayMs = 500,
|
|
|
|
spinnerVariant = "overlay",
|
2020-09-21 18:50:27 -07:00
|
|
|
doTransitions = false,
|
2020-09-24 06:13:27 -07:00
|
|
|
onChangeHasAnimations = null,
|
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
|
|
|
isPaused = true,
|
2020-07-22 22:07:45 -07:00
|
|
|
}) {
|
2020-09-21 18:11:25 -07:00
|
|
|
const containerRef = React.useRef(null);
|
|
|
|
const [canvasSize, setCanvasSize] = React.useState(0);
|
2020-09-13 04:12:14 -07:00
|
|
|
const [loadingDelayHasPassed, setLoadingDelayHasPassed] = React.useState(
|
|
|
|
false
|
|
|
|
);
|
|
|
|
|
2020-09-22 01:44:24 -07:00
|
|
|
const { loading: loadingEasel } = useEaselDependenciesLoader();
|
|
|
|
const loadingAnything = loading || loadingEasel;
|
|
|
|
|
2020-09-21 19:03:17 -07:00
|
|
|
// When we start in a loading state, or re-enter a loading state, start the
|
|
|
|
// loading delay timer.
|
2020-09-13 04:12:14 -07:00
|
|
|
React.useEffect(() => {
|
2020-09-22 01:44:24 -07:00
|
|
|
if (loadingAnything) {
|
2020-09-21 19:03:17 -07:00
|
|
|
setLoadingDelayHasPassed(false);
|
|
|
|
const t = setTimeout(
|
|
|
|
() => setLoadingDelayHasPassed(true),
|
|
|
|
loadingDelayMs
|
|
|
|
);
|
|
|
|
return () => clearTimeout(t);
|
|
|
|
}
|
2020-09-22 01:44:24 -07:00
|
|
|
}, [loadingDelayMs, loadingAnything]);
|
2020-07-22 22:07:45 -07:00
|
|
|
|
2020-09-21 18:11:25 -07:00
|
|
|
React.useLayoutEffect(() => {
|
2020-09-24 08:29:56 -07:00
|
|
|
function computeAndSaveCanvasSize() {
|
2020-09-21 18:11:25 -07:00
|
|
|
setCanvasSize(
|
2020-10-10 04:32:53 -07:00
|
|
|
// Follow an algorithm similar to the <img> sizing: a square that
|
|
|
|
// covers the available space, without exceeding the natural image size
|
|
|
|
// (which is 600px).
|
|
|
|
//
|
|
|
|
// TODO: Once we're entirely off PNGs, we could drop the 600
|
|
|
|
// requirement, and let SVGs and movies scale up as far as they
|
|
|
|
// want...
|
2020-09-21 18:11:25 -07:00
|
|
|
Math.min(
|
|
|
|
containerRef.current.offsetWidth,
|
2020-10-10 04:32:53 -07:00
|
|
|
containerRef.current.offsetHeight,
|
|
|
|
600
|
2020-09-21 18:11:25 -07:00
|
|
|
)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2020-09-24 08:29:56 -07:00
|
|
|
computeAndSaveCanvasSize();
|
|
|
|
window.addEventListener("resize", computeAndSaveCanvasSize);
|
|
|
|
return () => window.removeEventListener("resize", computeAndSaveCanvasSize);
|
2020-09-21 18:11:25 -07:00
|
|
|
}, [setCanvasSize]);
|
|
|
|
|
2020-04-23 15:19:36 -07:00
|
|
|
return (
|
2020-08-01 01:35:27 -07:00
|
|
|
<Box
|
|
|
|
pos="relative"
|
|
|
|
height="100%"
|
|
|
|
width="100%"
|
|
|
|
// Create a stacking context, so the z-indexed layers don't escape!
|
|
|
|
zIndex="0"
|
2020-09-21 18:11:25 -07:00
|
|
|
ref={containerRef}
|
2020-08-01 01:35:27 -07:00
|
|
|
>
|
2020-07-22 22:07:45 -07:00
|
|
|
{placeholder && (
|
|
|
|
<FullScreenCenter>
|
|
|
|
<Box
|
|
|
|
// We show the placeholder until there are visible layers, at which
|
|
|
|
// point we fade it out.
|
|
|
|
opacity={visibleLayers.length === 0 ? 1 : 0}
|
|
|
|
transition="opacity 0.2s"
|
|
|
|
>
|
|
|
|
{placeholder}
|
|
|
|
</Box>
|
|
|
|
</FullScreenCenter>
|
|
|
|
)}
|
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
|
|
|
<TransitionGroup enter={false} exit={doTransitions}>
|
|
|
|
{visibleLayers.map((layer) => (
|
|
|
|
<CSSTransition
|
|
|
|
// We manage the fade-in and fade-out separately! The fade-out
|
|
|
|
// happens here, when the layer exits the DOM.
|
|
|
|
key={layer.id}
|
|
|
|
classNames={css`
|
|
|
|
&-exit {
|
|
|
|
opacity: 1;
|
|
|
|
}
|
2020-09-21 18:50:27 -07:00
|
|
|
|
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
|
|
|
&-exit-active {
|
|
|
|
opacity: 0;
|
|
|
|
transition: opacity 0.2s;
|
|
|
|
}
|
|
|
|
`}
|
|
|
|
timeout={200}
|
|
|
|
>
|
2020-10-10 03:46:23 -07:00
|
|
|
<FadeInOnLoad as={FullScreenCenter} zIndex={layer.zone.depth}>
|
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
|
|
|
{layer.canvasMovieLibraryUrl ? (
|
|
|
|
<OutfitMovieLayer
|
|
|
|
libraryUrl={layer.canvasMovieLibraryUrl}
|
|
|
|
width={canvasSize}
|
|
|
|
height={canvasSize}
|
|
|
|
isPaused={isPaused}
|
|
|
|
/>
|
|
|
|
) : (
|
2020-10-10 03:46:23 -07:00
|
|
|
<Box
|
|
|
|
as="img"
|
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:19:59 -07:00
|
|
|
src={getBestImageUrlForLayer(layer).src}
|
|
|
|
// The crossOrigin prop isn't strictly necessary for loading
|
|
|
|
// here (<img> tags are always allowed through CORS), but
|
|
|
|
// this means we make the same request that the Download
|
|
|
|
// button makes, so it can use the cached version of this
|
|
|
|
// image instead of requesting it again with crossOrigin!
|
|
|
|
crossOrigin={getBestImageUrlForLayer(layer).crossOrigin}
|
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
|
|
|
alt=""
|
2020-10-10 03:37:43 -07:00
|
|
|
objectFit="contain"
|
|
|
|
maxWidth="100%"
|
|
|
|
maxHeight="100%"
|
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
|
|
|
/>
|
|
|
|
)}
|
2020-10-10 03:46:23 -07:00
|
|
|
</FadeInOnLoad>
|
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
|
|
|
</CSSTransition>
|
|
|
|
))}
|
|
|
|
</TransitionGroup>
|
2020-08-31 18:57:29 -07:00
|
|
|
<FullScreenCenter
|
|
|
|
zIndex="9000"
|
2020-06-05 23:56:42 -07:00
|
|
|
// This is similar to our Delay util component, but Delay disappears
|
2020-07-22 22:07:45 -07:00
|
|
|
// immediately on load, whereas we want this to fade out smoothly. We
|
2020-09-13 04:12:14 -07:00
|
|
|
// also use a timeout to delay the fade-in by 0.5s, but don't delay the
|
|
|
|
// fade-out at all. (The timeout was an awkward choice, it was hard to
|
|
|
|
// find a good CSS way to specify this delay well!)
|
2020-09-22 01:44:24 -07:00
|
|
|
opacity={loadingAnything && loadingDelayHasPassed ? 1 : 0}
|
2020-09-13 04:12:14 -07:00
|
|
|
transition="opacity 0.2s"
|
2020-06-05 23:56:42 -07:00
|
|
|
>
|
2020-09-13 04:12:14 -07:00
|
|
|
{spinnerVariant === "overlay" && (
|
|
|
|
<>
|
|
|
|
<Box
|
|
|
|
position="absolute"
|
|
|
|
top="0"
|
|
|
|
left="0"
|
|
|
|
right="0"
|
|
|
|
bottom="0"
|
|
|
|
backgroundColor="gray.900"
|
|
|
|
opacity="0.7"
|
|
|
|
/>
|
|
|
|
{/* Against the dark overlay, use the Dark Mode spinner. */}
|
|
|
|
<DarkMode>
|
|
|
|
<HangerSpinner />
|
|
|
|
</DarkMode>
|
|
|
|
</>
|
|
|
|
)}
|
|
|
|
{spinnerVariant === "corner" && (
|
|
|
|
<HangerSpinner size="sm" position="absolute" bottom="2" right="2" />
|
|
|
|
)}
|
2020-08-31 18:57:29 -07:00
|
|
|
</FullScreenCenter>
|
2020-05-02 13:40:37 -07:00
|
|
|
</Box>
|
2020-04-23 15:19:36 -07:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2020-08-31 18:57:29 -07:00
|
|
|
export function FullScreenCenter({ children, ...otherProps }) {
|
2020-04-23 13:31:39 -07:00
|
|
|
return (
|
|
|
|
<Flex
|
2020-04-23 15:19:36 -07:00
|
|
|
pos="absolute"
|
|
|
|
top="0"
|
|
|
|
right="0"
|
|
|
|
bottom="0"
|
|
|
|
left="0"
|
2020-04-23 13:31:39 -07:00
|
|
|
alignItems="center"
|
|
|
|
justifyContent="center"
|
2020-08-31 18:57:29 -07:00
|
|
|
{...otherProps}
|
2020-04-23 13:31:39 -07:00
|
|
|
>
|
|
|
|
{children}
|
|
|
|
</Flex>
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
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:19:59 -07:00
|
|
|
export function getBestImageUrlForLayer(layer) {
|
2020-05-11 21:19:34 -07:00
|
|
|
if (layer.svgUrl) {
|
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:19:59 -07:00
|
|
|
return { src: safeImageUrl(layer.svgUrl) };
|
2020-05-11 21:19:34 -07:00
|
|
|
} else {
|
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:19:59 -07:00
|
|
|
return { src: layer.imageUrl, crossOrigin: "anonymous" };
|
2020-05-11 21:19:34 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-06-05 23:56:42 -07:00
|
|
|
/**
|
|
|
|
* usePreloadLayers preloads the images for the given layers, and yields them
|
|
|
|
* when done. This enables us to keep the old outfit preview on screen until
|
|
|
|
* all the new layers are ready, then show them all at once!
|
|
|
|
*/
|
2020-07-22 21:29:57 -07:00
|
|
|
export function usePreloadLayers(layers) {
|
2020-06-05 23:56:42 -07:00
|
|
|
const [error, setError] = React.useState(null);
|
|
|
|
const [loadedLayers, setLoadedLayers] = React.useState([]);
|
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
|
|
|
const [layersHaveAnimations, setLayersHaveAnimations] = React.useState(false);
|
2020-06-05 23:56:42 -07:00
|
|
|
|
2020-08-31 18:41:57 -07:00
|
|
|
// NOTE: This condition would need to change if we started loading one at a
|
|
|
|
// time, or if the error case would need to show a partial state!
|
|
|
|
const loading = loadedLayers !== layers;
|
|
|
|
|
2020-06-05 23:56:42 -07:00
|
|
|
React.useEffect(() => {
|
2020-08-31 18:41:57 -07:00
|
|
|
// HACK: Don't clear the preview when we have zero layers, because it
|
|
|
|
// usually means the parent is still loading data. I feel like this isn't
|
|
|
|
// the right abstraction, though...
|
|
|
|
if (loadedLayers.length > 0 && layers.length === 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the layers already match, we can ignore extra effect triggers.
|
|
|
|
if (!loading) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-06-05 23:56:42 -07:00
|
|
|
let canceled = false;
|
|
|
|
setError(null);
|
|
|
|
|
2020-09-24 06:25:52 -07:00
|
|
|
const loadAssets = async () => {
|
|
|
|
const assetPromises = layers.map((layer) => {
|
|
|
|
if (layer.canvasMovieLibraryUrl) {
|
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
|
|
|
return loadMovieLibrary(layer.canvasMovieLibraryUrl).then(
|
|
|
|
(library) => ({
|
|
|
|
type: "movie",
|
|
|
|
library,
|
|
|
|
libraryUrl: layer.canvasMovieLibraryUrl,
|
|
|
|
})
|
|
|
|
);
|
2020-09-24 06:25:52 -07:00
|
|
|
} else {
|
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
|
|
|
return loadImage(getBestImageUrlForLayer(layer)).then((image) => ({
|
|
|
|
type: "image",
|
|
|
|
image,
|
|
|
|
}));
|
2020-09-24 06:25:52 -07:00
|
|
|
}
|
|
|
|
});
|
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
|
|
|
|
|
|
|
let assets;
|
2020-06-05 23:56:42 -07:00
|
|
|
try {
|
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
|
|
|
assets = await Promise.all(assetPromises);
|
2020-06-05 23:56:42 -07:00
|
|
|
} catch (e) {
|
|
|
|
if (canceled) return;
|
|
|
|
console.error("Error preloading outfit layers", e);
|
2020-10-10 02:37:37 -07:00
|
|
|
assetPromises.forEach((p) => {
|
|
|
|
if (p.cancel) {
|
|
|
|
p.cancel();
|
|
|
|
}
|
|
|
|
});
|
2020-06-05 23:56:42 -07:00
|
|
|
setError(e);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (canceled) return;
|
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
|
|
|
|
2020-10-22 23:52:26 -07:00
|
|
|
let movieClips;
|
|
|
|
try {
|
|
|
|
movieClips = assets
|
|
|
|
.filter((a) => a.type === "movie")
|
|
|
|
.map((a) => buildMovieClip(a.library, a.libraryUrl));
|
|
|
|
} catch (e) {
|
|
|
|
console.error("Error building movie clips", e);
|
|
|
|
assetPromises.forEach((p) => {
|
|
|
|
if (p.cancel) {
|
|
|
|
p.cancel();
|
|
|
|
}
|
|
|
|
});
|
|
|
|
setError(e);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
setLayersHaveAnimations(movieClips.some(hasAnimations));
|
2020-06-05 23:56:42 -07:00
|
|
|
setLoadedLayers(layers);
|
|
|
|
};
|
|
|
|
|
2020-09-24 06:25:52 -07:00
|
|
|
loadAssets();
|
2020-06-05 23:56:42 -07:00
|
|
|
|
|
|
|
return () => {
|
|
|
|
canceled = true;
|
|
|
|
};
|
2020-08-31 19:31:37 -07:00
|
|
|
}, [layers, loadedLayers.length, loading]);
|
2020-06-05 23:56:42 -07:00
|
|
|
|
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
|
|
|
return { loading, error, loadedLayers, layersHaveAnimations };
|
2020-06-05 23:56:42 -07:00
|
|
|
}
|
|
|
|
|
2020-10-10 03:37:43 -07:00
|
|
|
/**
|
2020-10-10 03:46:23 -07:00
|
|
|
* FadeInOnLoad attaches an `onLoad` handler to its single child, and fades in
|
|
|
|
* the container element once it triggers.
|
2020-10-10 03:37:43 -07:00
|
|
|
*/
|
2020-10-10 03:46:23 -07:00
|
|
|
function FadeInOnLoad({ children, ...props }) {
|
2020-10-10 03:37:43 -07:00
|
|
|
const [isLoaded, setIsLoaded] = React.useState(false);
|
|
|
|
|
2020-10-10 03:46:23 -07:00
|
|
|
const onLoad = React.useCallback(() => setIsLoaded(true), []);
|
|
|
|
|
|
|
|
const child = React.Children.only(children);
|
|
|
|
const wrappedChild = React.cloneElement(child, { onLoad });
|
|
|
|
|
2020-10-10 03:37:43 -07:00
|
|
|
return (
|
2020-10-10 03:46:23 -07:00
|
|
|
<Box opacity={isLoaded ? 1 : 0} transition="opacity 0.2s" {...props}>
|
|
|
|
{wrappedChild}
|
|
|
|
</Box>
|
2020-10-10 03:37:43 -07:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2020-04-23 13:31:39 -07:00
|
|
|
export default OutfitPreview;
|