4 ms·

You use WebGL to create standard GUI applications on the desktop? WebGL and canvas are in no way replacements for the DOM.

coldtea 12y ago
>You use WebGL to create standard GUI applications on the desktop? Increasinly high end apps do.
- RussianCow 12y ago
  Graphically intensive apps do it for performance. But the tradeoff is you lose all the native UI controls that the OS gives you--form fields, text selection, animation, etc. So I don't think replacing the DOM with OpenGL or similar is a good solution for general-purpose apps.
  - adamnemecek 12y ago
    All of those would be implemented in a framework.
    - bzbarsky 12y ago
      Yes, they already are. That framework is called the DOM. People keep complaining about it and trying to come up with replacement frameworks that end up slower and less capable... The DOM definitely has its problems, mind you. Investing some time in designing a proper replacement for it is worth it, as long as people understand going in that the project might well fail.
      - adamnemecek 12y ago
        Which framework has tried to replace the DOM?
        bzbarsky 12y ago
        None have tried to replace all of it that I know of. People have tried to replace things like text editing (with canvas-based editors), CSS layout of the DOM (with various JS solutions involving absolute positioning), native MathML support (MathJax; this one has of necessity done better than most, because of so many browsers not having native MathML support). There are a bunch of things out there that attempt to replace or augment the built-in form controls, with varying degrees of success.
        adamnemecek 12y ago
        That's my point. Currently, you cannot really replace the DOM since that's kind of the extent of the exposed APIs. None of the projects that you mention are really relevant to the discussion. I agree that they didn't change shit but it's precisely because they are still built on the DOM and cannot really go below that in the abstraction layer.
        coldtea 12y ago
        >I agree that they didn't change shit but it's precisely because they are still built on the DOM and cannot really go below that in the abstraction layer. There exist UIs done in Canvas and WebGL that are arguably below the DOM in the "abstraction layer" and don't need to use much more DOM nodes besides opening a canvas/gl panel... (Most full screen 2G/3G web games fall into this, for starters, and those are in the tens of thousands. But there are also lotsa apps).
        xxgreg 12y ago
        > None have tried to replace all of it that I know of. https://github.com/domokit/mojo/tree/master/sky https://github.com/domokit/mojo/tree/master/sky https://github.com/domokit/mojo/tree/master/sky/specs https://github.com/domokit/mojo/tree/master/sky/specs
        comex 12y ago
        Flipboard's from the recent story? The resulting site breaks accessibility and the layout obviously has less capability, but it's certainly not slower.
      - coldtea 12y ago
        >Yes, they already are. That framework is called the DOM. People keep complaining about it and trying to come up with replacement frameworks that end up slower and less capable... The ones I've seen are actually faster -- Flipboard for one gets to 60fps scrolling on mobile, IIRC. And of course all WebGL based interfaces on native mobile apps that re-implement parts of Cocoa Touch et al, are not that shabby either. Sure, it doesn't have as much accesibility, but that's something that can be fixed in the future (and of course people needing more accessibility can always use more conservative alternatives).
adamnemecek 12y ago
E.g. Mac OS X uses OpenGL to render GUI, I guess I should have made myself more clear. > WebGL and canvas are in no way replacements for the DOM. That's kind of debatable. If you have access to a fast graphics layer from the browser, you can build a DOM replacement of sorts. I think that famo.us works kind of like that.
- RussianCow 12y ago
  To some degree, yes. You just have to be able to re-use system UI controls like fields. So you wouldn't be able to just use WebGL/canvas/whatever in place of the DOM, you'd need to come up with a new API.
  - adamnemecek 12y ago
    I know. I was thinking that there'd be something like Qt that would render the widgets using WebGL.
    - RussianCow 12y ago
      Until the web becomes the dominant operating system, I don't think that's reasonable because you'd have to implement an entire UI kit (with all UI components, behaviors, animations, etc) but can't guarantee that it will behave at all like the underlying OS. There's only so much you can re-create in the browser.
- pavlov 12y ago
  It's true that OS X uses OpenGL for GUI compositing, but that's only the lowest level. Above, there's a very important piece of the GUI stack called Core Animation which provides layer compositing. Core Animation is used by both the native GUI as well as the browser DOM. When you use layer-backed compositing on a web page (e.g. CSS 3D transforms), WebKit implements it with a Core Animation layer. So DOM-based rendering enjoys the same benefits of GPU-accelerated compositing as native apps -- although obviously with rather different semantics since HTML+CSS doesn't map directly to Core Animation. If you implement your own GUI framework on top of WebGL or Canvas, you're not getting Core Animation compositing for free, so you need to replicate that functionality in your custom framework. (This applies equally to native apps: a WebGL app is equivalent to a Cocoa app that renders everything into a single OpenGL view, and a HTML Canvas app is equivalent to using a single CoreGraphics view.) I don't think the WebGL/Canvas route makes sense for most apps other than games and highly visual 3D apps. You'll just spend a huge amount of time building your own implementations of all high-level functionality that is already provided by the OS and/or the browser: layer compositing, text layout, view autosizing, and so on. If you're doing standard GUIs, why go to all that trouble?
runeks 12y ago
Perhaps it's to make it backward compatible, so that, for example, the traditional DOM is implemented as a Javascript library that parses HTML and renders it onto a WebGL surface?

coldtea 12y ago

>You use WebGL to create standard GUI applications on the desktop? Increasinly high end apps do.

RussianCow 12y ago
Graphically intensive apps do it for performance. But the tradeoff is you lose all the native UI controls that the OS gives you--form fields, text selection, animation, etc. So I don't think replacing the DOM with OpenGL or similar is a good solution for general-purpose apps.
- adamnemecek 12y ago
  All of those would be implemented in a framework.
  - bzbarsky 12y ago
    Yes, they already are. That framework is called the DOM. People keep complaining about it and trying to come up with replacement frameworks that end up slower and less capable... The DOM definitely has its problems, mind you. Investing some time in designing a proper replacement for it is worth it, as long as people understand going in that the project might well fail.
    - adamnemecek 12y ago
      Which framework has tried to replace the DOM?
      - bzbarsky 12y ago
        None have tried to replace all of it that I know of. People have tried to replace things like text editing (with canvas-based editors), CSS layout of the DOM (with various JS solutions involving absolute positioning), native MathML support (MathJax; this one has of necessity done better than most, because of so many browsers not having native MathML support). There are a bunch of things out there that attempt to replace or augment the built-in form controls, with varying degrees of success.
        adamnemecek 12y ago
        That's my point. Currently, you cannot really replace the DOM since that's kind of the extent of the exposed APIs. None of the projects that you mention are really relevant to the discussion. I agree that they didn't change shit but it's precisely because they are still built on the DOM and cannot really go below that in the abstraction layer.
        coldtea 12y ago
        >I agree that they didn't change shit but it's precisely because they are still built on the DOM and cannot really go below that in the abstraction layer. There exist UIs done in Canvas and WebGL that are arguably below the DOM in the "abstraction layer" and don't need to use much more DOM nodes besides opening a canvas/gl panel... (Most full screen 2G/3G web games fall into this, for starters, and those are in the tens of thousands. But there are also lotsa apps).
        xxgreg 12y ago
        > None have tried to replace all of it that I know of. https://github.com/domokit/mojo/tree/master/sky https://github.com/domokit/mojo/tree/master/sky https://github.com/domokit/mojo/tree/master/sky/specs https://github.com/domokit/mojo/tree/master/sky/specs
      - comex 12y ago
        Flipboard's from the recent story? The resulting site breaks accessibility and the layout obviously has less capability, but it's certainly not slower.
    - coldtea 12y ago
      >Yes, they already are. That framework is called the DOM. People keep complaining about it and trying to come up with replacement frameworks that end up slower and less capable... The ones I've seen are actually faster -- Flipboard for one gets to 60fps scrolling on mobile, IIRC. And of course all WebGL based interfaces on native mobile apps that re-implement parts of Cocoa Touch et al, are not that shabby either. Sure, it doesn't have as much accesibility, but that's something that can be fixed in the future (and of course people needing more accessibility can always use more conservative alternatives).

adamnemecek 12y ago

E.g. Mac OS X uses OpenGL to render GUI, I guess I should have made myself more clear. > WebGL and canvas are in no way replacements for the DOM. That's kind of debatable. If you have access to a fast graphics layer from the browser, you can build a DOM replacement of sorts. I think that famo.us works kind of like that.

RussianCow 12y ago
To some degree, yes. You just have to be able to re-use system UI controls like fields. So you wouldn't be able to just use WebGL/canvas/whatever in place of the DOM, you'd need to come up with a new API.
- adamnemecek 12y ago
  I know. I was thinking that there'd be something like Qt that would render the widgets using WebGL.
  - RussianCow 12y ago
    Until the web becomes the dominant operating system, I don't think that's reasonable because you'd have to implement an entire UI kit (with all UI components, behaviors, animations, etc) but can't guarantee that it will behave at all like the underlying OS. There's only so much you can re-create in the browser.
pavlov 12y ago
It's true that OS X uses OpenGL for GUI compositing, but that's only the lowest level. Above, there's a very important piece of the GUI stack called Core Animation which provides layer compositing. Core Animation is used by both the native GUI as well as the browser DOM. When you use layer-backed compositing on a web page (e.g. CSS 3D transforms), WebKit implements it with a Core Animation layer. So DOM-based rendering enjoys the same benefits of GPU-accelerated compositing as native apps -- although obviously with rather different semantics since HTML+CSS doesn't map directly to Core Animation. If you implement your own GUI framework on top of WebGL or Canvas, you're not getting Core Animation compositing for free, so you need to replicate that functionality in your custom framework. (This applies equally to native apps: a WebGL app is equivalent to a Cocoa app that renders everything into a single OpenGL view, and a HTML Canvas app is equivalent to using a single CoreGraphics view.) I don't think the WebGL/Canvas route makes sense for most apps other than games and highly visual 3D apps. You'll just spend a huge amount of time building your own implementations of all high-level functionality that is already provided by the OS and/or the browser: layer compositing, text layout, view autosizing, and so on. If you're doing standard GUIs, why go to all that trouble?

runeks 12y ago

Perhaps it's to make it backward compatible, so that, for example, the traditional DOM is implemented as a Javascript library that parses HTML and renders it onto a WebGL surface?