4 ms·

(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 tha

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

by spicyj 13y ago

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.