Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Speed of passage rendering

edited May 2015 in Help! with 1.x
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:
<<timedcontinue 0.1s>>
<<imageswapmacro>>

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.

Comments

  • Someone else may have a better answer but this question is a bit like asking "How long is a piece of string", the answer is it depends!

    It depends mostly on the specs of the machine/device doing the rendering of the image.

    eg.
    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.
  • edited May 2015
    I'm not sure that the speed of the image rendering is in issue, as I think there is still a delay there. It's just any remaining delay is hidden by the passage transition being flashy over the top. What causes jerkyness is when the browser chooses to render the image before the passage. Because then the browser will delay showing the passage until it figures out the image, even if rendering the passage takes 1ms and the image takes 2 seconds.

    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.
  • edited May 2015
    Preliminary tests seem to show that putting all my image swap macros in
    PassageDone
    
    appears to have fixed the stuttering issue without any delay required.

    Will see if it holds up.

    I.e. something like in main passage:
    <<set $thispassage to 1>>
    <<set $thatpassage to 0>>
    

    And in PassageDone:
    <<if $thispassage is 1>>
    <<thispassageimage>>
    <<elseif $thatpassage is 1>>
    <<thatpassageimage>>
    <</if>>
    

    The only remaining question is whether there's a cleaner way to do that, using passage tags or whatnot.
  • edited May 2015
    Hmmm no, scratch that.

    Still results in a delay sometimes.

    But some other experiments:

    Using
    <<timedcontinue 1ms>>
    

    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.
  • edited May 2015
    You are not actually receiving a 1 ms delay. Both of the standard timer functions (setTimeout() and setInterval()), which are used by <<timedcontinue>>, have a built-in minimum delay. The delay has, traditionally, varied from browser to browser (anywhere from 5–16 ms), but was finally set as part of the HTML5 specification family to 4 ms.

    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.
  • Oh well, I'll just set it to 50ms just to be safe.
  • edited May 2015
    While PassageDone didn't work out, it seems I'm getting much better results with PassageReady without needing a delay.

    EDIT: Although still not as snappy as the delay version.
Sign In or Register to comment.