Scrollable content not working after animating an element


(Mohammad Khan) #1

Hi,
This is my first question on the Tumult Hype forums. I work at a University and am working on designing interactive content for our students. Part of this includes a built in Document Browser with PDF links to slideshows. I made a small DocumentBrowser UI that has the DocumentsTableViewController Group’s Content Property set to Scrollbars. The scrolling interaction works perfectly when the entire DocumentsBrowser is not animated into the scene, however, when I animate it in, the scrolling interaction is no longer working so the user can’t see the list of documents beyond the current bounds of the group.

I have attached a hype document with two scenes, one which has Browser without animation and one with. I would like to have the browser animate in, because it will overlay on top of another scene with content on it.
DocumentsBrowserTest.hype.zip (68.8 KB)


#2

Hi Mohammad:

Welcome to the forums!

Can you let me know what browser or device you’re testing in? In Chrome & Safari I’m able to scroll around using a scroll wheel and on an iPad using touch – in both interfaces I’m able to see all items.


#3

Hi Mohammad!

This seems to be some kind of bug~conflict in particular set-ups as @Daniel did not have any problems in Chrome or Safari. But I did under certain circumstances.

Note: All below use OSX 10.11.6; Hype 3.6.3 (584).

Chrome (60.0.3112.90), Firefox (54.0.1), Opera (44.0.2510.1218) do work properly for me.

Safari 10.1.1 - I have the same issue as You - the animated page does not scroll properly. But the following (2) options work in my set-up.

Option 1: Checking the “Position with CSS left/top” in Hype’s “Document Inspector” Safari 10.1.1 does work. Note: It scrolls but scrollbars are not shown in my rendering.

Option 2: Uncheck “Use WebKit graphics acceleration” (shown “checked” in Fig. 1 below).
Note: The scrollbars are shown in my rendering. You do not need to also use “Option 1”.

Fig.1 - “Document Inspector” screenshot crop



So this is where it gets interesting: DocumentsBrowserTest_JHS.hype.zip (81.2 KB)

Using your original file… I re-did your animated scene so it was showing in the Scene to start (not below the Scene boundary as in your version). It worked in Safari. Neither “Option 1” or “Option 2” was used. All settings in the “Document Inspector” the same as your original.


(Mohammad Khan) #4

I am using macOS Sierra (10.12.6) with Hype Version 3.6.3 (584) running on Safari 10.1.2.


(Mohammad Khan) #5

I just tried using Option 1 and the scrolling works and I am able to see the scrollbars renders in Safari, but my Safari is 10.1.2. Do you know what Option 1 actually does under the hood, I am still unclear as to why that fixed it?


(Jonathan Deutsch) #6

Hype makes many choices on how it positions and displays content to optimize for most documents on how content is rendered and animation performance. Position with CSS left/top will use the CSS left/top properties instead of using transform:translate() to position elements, with the main disadvantage being elements cannot be rendered on fractional pixels and thus may look choppier when animating especially at slow speeds. Use WebKit graphics acceleration puts a 3D rotation on elements forcing the graphics card to do compositing. This usually is a performance improvements but is a different rendering path and can hit a different subset of rendering bugs.

The most “vanilla” way to have content is to use the Position with CSS left/top enabled and Use WebKit graphics acceleration disabled. Without looking too deeply there’s probably bugs in Safari’s rendering when going outside of this path.


#7

When animating the positioning of elements the default is to use ‘Transforms’ which is in most respect better and more performant than using CSS values like top and left to set the position of elements. This seems like an odd case where transforms + webkit acceleration affects scrolling in Safari.

It looks like this bug is fixed in Webkit nightly, which should mean that these fixes will make it into the next Safari update. Until then, Option 1 or 2 will workaround this issue.


(Mohammad Khan) #8

Thanks everyone for the help with this one!