4 ms·

This is a cool idea. The website says it is untested on android and it shows how weird and inconsistent browsers are. On android firefox it looks like the iPh

This is a cool idea. The website says it is untested on android and it shows how weird and inconsistent browsers are. On android firefox it looks like the iPhone example but the light movement is very choppy (maybe hardware acceleration is missing or something like that). On chrome the movement is smooth but the markup is not rendered correctly.

onion2k 8y ago
maybe hardware acceleration is missing or something like that It's doing some seriously slow stuff behind the scenes. For example, when the library initialises it creates a 64 * pixelDensity square canvas and then loops through all the pixels in it one by one using a randomly generated transparent color value to draw a 1x1 rectangle to each one (See the 'generateNoise()' function in https://github.com/rikschennink/shiny/blob/master/src/index.js https://github.com/rikschennink/shiny/blob/master/src/index....). That's just slooooow. HTML5's canvas API has a putImageData method that is much faster because all you're really doing when you fill an image is assigning values to a UINT8 typed array with 4 values per pixel. It'd be relatively straightforward to achieve this effect using WebGL and a quad to overlay the element, and just pass in the orientation data as a vec2 uniform. That's how some of the effects in my React Neon library work (https://react-neon.ooer.com/ https://react-neon.ooer.com/) for mouse coordinates. Although, that said, Neon is Chrome-only because it relies on ResizeObserver at the moment. One day I'll fix that...
- rikschennink 8y ago
  It does that once, and it does it to prevent having to ship an image or base64 encoded string to create a noise effect. It's a balancing act between a bigger library and CPU usage. It takes the CPU 15 milliseconds (it's more than I expected, but it's on page load). Good to know that putImageData is faster, will look into that. What is most likely causing the chopiness is that it's animating background gradients. There is a lot of room for improvement there, instead of animating the background gradient we could transform a layer instead. Anyway, PR's are always welcome.
  - yoklov 8y ago
    15ms for that is ridiculously slow, but if you’re doing single pixel rectangles... that would do it.
- codetrotter 8y ago
  > https://react-neon.ooer.com/ https://react-neon.ooer.com/ Using Firefox 64.0 on KDE Neon 18.04, the contents of this page shows up for a brief moment but then goes white.
  - onion2k 8y ago
    Cheers. It's the same in OSX Firefox (and everything that isn't Chrome) as "window.ResizeObserver is not a constructor". When I get time I'll fix that.

onion2k 8y ago

maybe hardware acceleration is missing or something like that It's doing some seriously slow stuff behind the scenes. For example, when the library initialises it creates a 64 * pixelDensity square canvas and then loops through all the pixels in it one by one using a randomly generated transparent color value to draw a 1x1 rectangle to each one (See the 'generateNoise()' function in https://github.com/rikschennink/shiny/blob/master/src/index.js https://github.com/rikschennink/shiny/blob/master/src/index....). That's just slooooow. HTML5's canvas API has a putImageData method that is much faster because all you're really doing when you fill an image is assigning values to a UINT8 typed array with 4 values per pixel. It'd be relatively straightforward to achieve this effect using WebGL and a quad to overlay the element, and just pass in the orientation data as a vec2 uniform. That's how some of the effects in my React Neon library work (https://react-neon.ooer.com/ https://react-neon.ooer.com/) for mouse coordinates. Although, that said, Neon is Chrome-only because it relies on ResizeObserver at the moment. One day I'll fix that...

rikschennink 8y ago
It does that once, and it does it to prevent having to ship an image or base64 encoded string to create a noise effect. It's a balancing act between a bigger library and CPU usage. It takes the CPU 15 milliseconds (it's more than I expected, but it's on page load). Good to know that putImageData is faster, will look into that. What is most likely causing the chopiness is that it's animating background gradients. There is a lot of room for improvement there, instead of animating the background gradient we could transform a layer instead. Anyway, PR's are always welcome.
- yoklov 8y ago
  15ms for that is ridiculously slow, but if you’re doing single pixel rectangles... that would do it.
codetrotter 8y ago
> https://react-neon.ooer.com/ https://react-neon.ooer.com/ Using Firefox 64.0 on KDE Neon 18.04, the contents of this page shows up for a brief moment but then goes white.
- onion2k 8y ago
  Cheers. It's the same in OSX Firefox (and everything that isn't Chrome) as "window.ResizeObserver is not a constructor". When I get time I'll fix that.