4 ms·

You're right! In fact, https://github.com/facebook/react-art https://github.com/facebook/react-art is a React library we developed at Facebook for rendering gra

You're right! In fact, https://github.com/facebook/react-art https://github.com/facebook/react-art is a React library we developed at Facebook for rendering graphics to Canvas, SVG, or VML, depending on what's fastest and what the browser supports. It's in production currently. Documentation's lacking but go check it out if you feel adventurous =).

davedx 13y ago
I work in digital TV, and we've been experimenting with using WebGL to build our interfaces lately as rendering the DOM on the GPU is so messy and complicated. Is there any prospect of a WebGL renderer for React? If not, how difficult would such a thing be to build by an eager third party? :)
- spicyj 13y ago
  (I work on React.) I don't know of anyone who's put work into a WebGL renderer, but it should be possible. There are a few pieces of React that still assume that you're rendering to the DOM but you can see that the react-art source is only around 600 lines for bindings to the underlying https://github.com/sebmarkbage/art https://github.com/sebmarkbage/art drawing library so it shouldn't be too hard (knock on wood!).
  - greggman 13y ago
    Unless I'm missing something the problem with canvas based shadow dom widgets is there is no per element resize event so if the element gets resized there's no way for the element to know it needs to redraw its content. The only resize event in the browser is on window so sizing a column for example or having an element's size change based on adding or removing other elements does not generate any events the shadow dom element would have access to
    - vjeux 13y ago
      If you use any renderer outside of the DOM then you need to implement your own layout engine. It means that you've got to figure out for each node that you output its left, top, width, height. CSS has its flaws but makes 95% of the use cases really easy to work with compared to any ofher mainstream UI abstraction.
      - greggman 13y ago
        As a simple example though, assume you wanted to make a Shadow DOM widget to show a visual representation of an audio sample, or any other kind of detailed graph. Something you arguably don't want to build a giant SVG tree for. Those seem like great things to do with shadow dom widgets... but ... they seem S.O.L without a per element resize event. I suppose that's being a little over the top. As long as you make them a fixed size or manually call some 'redraw' function when your app notices they've been resized then you're fine. It's just part of the point of Shadow DOM is you're not suppose to have to do that. They should "just work" just like normal HTML elements and size and redraw themselves. It would be nice if there was a way to do that for more interesting canvas based widgets.
- ttty 13y ago
  You could use PIXI.js
- lobo_tuerto 13y ago
  You might be interested in this then (Famo.us): https://news.ycombinator.com/item?id=7558261 https://news.ycombinator.com/item?id=7558261
  - davedx 13y ago
    We've looked at Famo.us too. In fact I've benchmarked the famo.us approach on our hardware, unfortunately for what we're doing CSS transitions appear to be marginally smoother.

davedx 13y ago

I work in digital TV, and we've been experimenting with using WebGL to build our interfaces lately as rendering the DOM on the GPU is so messy and complicated. Is there any prospect of a WebGL renderer for React? If not, how difficult would such a thing be to build by an eager third party? :)

spicyj 13y ago
(I work on React.) I don't know of anyone who's put work into a WebGL renderer, but it should be possible. There are a few pieces of React that still assume that you're rendering to the DOM but you can see that the react-art source is only around 600 lines for bindings to the underlying https://github.com/sebmarkbage/art https://github.com/sebmarkbage/art drawing library so it shouldn't be too hard (knock on wood!).
- greggman 13y ago
  Unless I'm missing something the problem with canvas based shadow dom widgets is there is no per element resize event so if the element gets resized there's no way for the element to know it needs to redraw its content. The only resize event in the browser is on window so sizing a column for example or having an element's size change based on adding or removing other elements does not generate any events the shadow dom element would have access to
  - vjeux 13y ago
    If you use any renderer outside of the DOM then you need to implement your own layout engine. It means that you've got to figure out for each node that you output its left, top, width, height. CSS has its flaws but makes 95% of the use cases really easy to work with compared to any ofher mainstream UI abstraction.
    - greggman 13y ago
      As a simple example though, assume you wanted to make a Shadow DOM widget to show a visual representation of an audio sample, or any other kind of detailed graph. Something you arguably don't want to build a giant SVG tree for. Those seem like great things to do with shadow dom widgets... but ... they seem S.O.L without a per element resize event. I suppose that's being a little over the top. As long as you make them a fixed size or manually call some 'redraw' function when your app notices they've been resized then you're fine. It's just part of the point of Shadow DOM is you're not suppose to have to do that. They should "just work" just like normal HTML elements and size and redraw themselves. It would be nice if there was a way to do that for more interesting canvas based widgets.
ttty 13y ago
You could use PIXI.js
lobo_tuerto 13y ago
You might be interested in this then (Famo.us): https://news.ycombinator.com/item?id=7558261 https://news.ycombinator.com/item?id=7558261
- davedx 13y ago
  We've looked at Famo.us too. In fact I've benchmarked the famo.us approach on our hardware, unfortunately for what we're doing CSS transitions appear to be marginally smoother.