In my story I have lots of large background images (2560 x 1440 px), and have discovered that the background switch cannot happen at the same time as the passage transition otherwise it gets "jammed" and jerkyness happens as the browser struggles to figure out what to process first.
So I solve this by writing in the passage using the SugarCube replace macro set:
This way the image swap is delayed 100ms while the passage renders, and it becomes smooth, since now the browser knows to fully render the passage first. I then use different transition lengths to hide the delay. (e.g. the passage transition is set to 1.5 seconds so it's still underway while the image transitions).
My question is... what's a "safe" timing value? I started with 0.5 seconds, and that left too much of a noticeable gap. So I gradually pared it back to 100ms, which still seems safe. How low could I go? I.e. How long should a passage take to render ideally?
I can, of course, just experiment. But I wanted to throw this out there to see if there was any expert input based on what people know what's happening underneath.
It depends mostly on the specs of the machine/device doing the rendering of the image.
If the image has to be down/up sized to fit a different screen resolution it will take longer.
If the story is hosted and you are not pre downloading the images then their internet speed could effect the time it takes.
What just needs to happen is the text of the passage needs to finish processing, then the image can take as long as it wants. So telling the browser to always, 100% process the passage before the image.
So I'm more asking what a safe speed of rending the text in a passage is.
EDIT: I'm also wondering if PassageDone special passage would be useful here.
Will see if it holds up.
I.e. something like in main passage:
And in PassageDone:
The only remaining question is whether there's a cleaner way to do that, using passage tags or whatnot.
Still results in a delay sometimes.
But some other experiments:
before the image swap works to completely remove the stutter. 1ms! I'm not sure if I want to cut it that fine, but it is interesting. The animation proceeds smoother and faster with that 1ms delay than if it didn't wait 1ms.
Setting animation-delay in CSS also works too, but also requires me to set the opacity of the incoming image down to 0 to start with, which produces some odd visual effects.
So, for browsers from about 2010 onward you're receiving 4 ms and prior to that 5–16 ms.
Not a huge difference, but worth knowing.
EDIT: Although still not as snappy as the delay version.