Re: Scroll linked effects in a WebGL context

Zitat von Kartikaya Gupta <kgupta@mozilla.com>:

> Hello Dr. Helmut,

Hello Kats,

>
> 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!

Thank you very much.

>
> 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.

I had this behaviour once (using nightly), when my computer was slow,  
the part of the
3D image on top or on bottom of the screen appeared only a short while
after scrolling. This can be provoked by using "window.onscroll=null"
on the console.

Normally I see an effect appearing at the edges between HTML and
WebGL content. Most of these edges are are realized by drawing
transparent pixels on the canvas so that HTML elements below the canvas
show through. I normally see no problems at the top and bottom of the
screen where the boundaries of the canvas are (although I actually
expected that).

I also see some kind of jitter effect some of the 3D objects appearing
twice, especially when quickly scrolling up and down.


> 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.
I think that the effect I am seeing comes from the WebGL drawing transparent
pixels at a position that does not fit together with the HTML content.


> 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?
I am already having a hard time to get a full screen canvas working
performantly, especially on mobile devices. 4k gpus are currently new,
however there are also many very slow GPUs where its necessary
to switch off many nice WebGL features to gain performance.


>
> 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?

My implementation uses (as usual in WebGL) rAF to generate each new frame.

In the onscroll event handler uses body.scrollTop to alter positions
of light sources and animated 3d objects.

In the rAF I do polling of window.devicePixelRatio to detect a zoom
event, but I do not check for a change of scrollTop.

With "window.onscroll=null" the 3D canvas scrolls nicely, the 3d
objects move up and down, but no longer in a parallax way.

Thanks,
Helmut
>
> Cheers,
> kats
>
>>
>> -
>> -------------------------------------------------------------------------
>>     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 21:22:34 UTC