Re: Scroll linked effects in a WebGL context

Hello Dr. Helmut,

Thanks for the email! This is certainly an interesting and creative
use of WebGL to implement scrolling effects. Some of the 3D effects
with objects popping "out of the page" are pretty neat!

While I was scrolling it in FF it looked like the most severe visual
issue with the new async scrolling code is at the edges of the canvas.
That is, the positioning of the canvas lags behind the scroll, and so
you often "uncover" a bit of the page without the canvas overlay as
you scroll. Then as the scroll event is fired the canvas shifts to the
correct position. It seems to me that making the canvas a little
larger than the visible area would solve that problem. There is an API
proposal to expose the "renderport" to web content [1] which would
allow you to size the canvas to the entire pre-rendered content area
(which is larger than what the user sees). I think sizing your canvas
to that would probably solve the issue I noticed. However, the
renderport tends to be much larger than the visible area, and it might
defeat your canvas size optimization entirely. Do you have an idea of
the upper bound of canvas size that performs well?

There is theoretically a second issue where the scroll event is used
to adjust what is actually drawn *in* the canvas, and so the position
of the various 3D objects would also lag behind. However, while
playing around with your site I wasn't able to reproduce that issue
(at least not the way I expected) so I'm not sure if you worked around
that in some other way, or if you're using rAF callbacks (as opposed
to scroll events) to update the position of your 3D objects. Were you
able to observe this sort of lag?

Cheers,
kats

[1] https://lists.w3.org/Archives/Public/public-whatwg-archive/2016Apr/0009.html

On Fri, Jun 3, 2016 at 3:12 PM, Dr. Helmut Emmelmann <emmel@taccgl.org> wrote:
> In response to
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Scroll-linked_effects
>
> I am using the following scroll linked effects in a WebGL context:
>
> 1. 3D Parallax Eye Position linked to Scroll
> A WebGL based 3D scene on the page changes its virtual eye position
> linked to scrolling. This automatically leads to a parallax scrolling
> effect. Described in http://www.taccgl.org/blog/parallax-scrolling.html
> and used on http://www.taccgl.org/
>
>
> 2. (WebGL) Canvas Size Optimization
> The size of an HTML canvas element is reduced (and position adapted) so that
> the
> remaining smaller canvas only covers visible parts of the original canvas.
>
> Note that the size (in device pixels) of a WebGL canvas is for practical
> applications limited by GPU performance. Because WebGL recalculates each
> pixel
> anew per frame, the number of device pixels of the canvas is crucial.
> I would like to use a canvas that covers a complete HTML document, which can
> be many screens long and much too big for WebGL. However, also by zooming
> into
> a fixed size (in CSS pixels) canvas it can grow very large measured in
> device pixels.
> Yet it can be displayed nicely with WebGL if only the visible pixels
> of the canvas are effectively rendered.
>
> Ideally the user just sees a 3D scene scrolling just like normal content,
> while
> internally the position of the canvas on the document changes and WebGL
> renders a different part of the 3D scene reflecting the scroll operation.
>
> This means that on scroll (as well as on window resize, zoom, pinch zoom and
> panning)
> position and possibly size of the canvas element changes and that the
> rendered WebGL
> content on the canvas also changes to show the then visible part of
> the 3D scene. It is important that changes of canvas position/size and
> of the canvas content take effect simultaneously on the next frame.
>
> Examples are http://taccgl.org/blog/HTMLpages-with-3D-objects.html (without
> parallax
> scrolling) and http://www.taccgl.org/ (with additional parallax scrolling).
>
>
>
> On my desktop computer, scrolling looks fine in Chrome, on slower mobile
> devices it becomes jumpy. On FF the webgl content seems to lag behind on
> scroll,
>
> Measurements show, that even on a desktop, there are dropped frames on a
> scroll, i.e. requestAnimationFrame is not called in time to maintain 60fps
> during the scroll operation. I use the onscroll handler to inform the WebGL
> about the scroll operation, so if this is called late,
> the WebGL content lags behind on scroll as it might be the case in FF.
>
>
>
> Helmut
>
>
>
> -
> -------------------------------------------------------------------------
>     H.E.I. Informationssysteme GmbH | Wimpfenerstraße 23  68259 Mannheim
> Germany, Tel: +49 621-795141 | Fax: +49 621-795161 | mailto:emmel@taccgl.org
>   Geschäftsführer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091
>              Handelsregister: HRB 7273 | Amtsgericht Mannheim
>     http://www.taccgl.org   http://www.taccgl.de  http://www.hei.de
> -------------------------------------------------------------------------
>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>

Received on Monday, 6 June 2016 15:29:13 UTC