This is maybe more of a potential browser issue than a Twine one, but I’m hoping for some insight, if anyone has any.
I’ve been tasked (or rather, collaborating) on making something in Twine that uses an abundance of graphical elements. My HTML work is shoddy, but I’m essentially rendering approximately 4 images; a large, screen-wide old-style TV, a CRT layer (using z-index layers) and then some other smaller images for facial expressions and other things.
All of this is formatted fine, looks great on the page and so on…the problem is that when I click links, all these graphical elements (apart from the background) “blink” in place as new text is generated in the next passage. It looks like everything sort of flickers in place. It only flickers for a fraction of a second, but it’s enough to be noticable, and when clicking a link to move to the next passage, there’s a momentarily lag of around half a second.
I am using div containers for it all apart from the actual background, which is the only thing not flickering. For those div containers, I’m using background-image in the stylesheet with an url directly to a neocities link of the image. This issue persists if I swap out div containers for img containers as well.
I’m not sure if this is just a limitation of Twine or HTML but is there a way I can potentially stop this from happening? Any insight would be appreciated. Thank you!
the HTML content for the Passage being visited is generated.
the tags attribute of the <tw-story> element is updated.
the existing <tw-passage> element is destroyed, along with all its descendent elements.
a new <tw-passage> structure is created, to represent the new state of the <tw-sidebar> area, and new Passage content.
Additional to the above, Harlowe uses a two stage rendering process to achieve the Passage Transtion visual effect associated with add new Passage content to the “passage” area:
a copy of the “content” is added to a special custom element, which in turn is added to the “passage” area for a brief period of time.
after that period has passed, that special custom element is destroyed, and the “content” itself is added to the “passage” area again.
So the flickering you’re seeing is likely caused by:
the destruction and recreation of “passage” area.
the fact that the Passage content is added twice to the new “passage” area.
any delay associated with the downloading of any previously unseen image.
the time it takes to render any image being shown.
And the reason that flickering doesn’t happed for the page’s background image:
the element the image is a background for isn’t being destroyed & recreated.
that image has already been downloaded and rendered.
There are techniques that can be used to reduce the delay related with the downloading of a previous unseen image, like doing image pre-loading with JavaScript, or using locally stored images instead of hosted ones.
There isn’t much you can do about Harlowe’s two stage rendering of the “passage” area.
I appreciate the response, Greyelf. I don’t know a lot about HTML so this is incredibly insightful and really gives it a new perspective for me. It looks like I still have a long way to go, but this is some interesting food for thought.
If it’s unavoidable, it’s unavoidable. Thank you for the insightful answer!
Greyelf has also solved the very same issue for me, albeit admittely the screen layout is much more simpler:
so, I suggest you to try moving the flickering graphical elements in a custom stylesheet, let’s say “tv_screen”, and add to the passage featuring said TV screen the tag “tv_screen”. Has worked for my problem, which is admittely much simpler (a change of background colour).