8 ms·

Render HTML via WebGL

186 points by PixelsCommander 12y ago

jeremiep 12y ago
It looks great, but I don't like the fact that I can't select the text anymore!
- PixelsCommander 12y ago
  It can be selected at same bounding box DOM node have and the selection will not be highlighted at the moment, but we will fix that.
  - riskable 12y ago
    If you can get text selection (and copy/paste) working please post how you did it. I wrote Gate One which is a web-based terminal emulator. Right now I have to go through great pains to ensure that text being rendered to the screen happens in a performant way while still allowing for copy & paste functionality. It also has some features that will highlight text that you select with your mouse and other text formatting stuff. I've experimented with canvas in the past to see if it could improve the performance of, say, a terminal that updates very quickly but it ultimately ended up being just as slow as the regular DOM because of all the extra code that had to be running in order to keep the hidden buffer in sync with what was displayed to the user. I'd be curious to know how the performance of WebGL compares to the (accelerated) canvas.
    - PixelsCommander 12y ago
      Performance is much better if translation / scaling / opacity / rotation are used or shaders ofcourse. If image content redraws by CPU it sucks. Basically it is what GPU can do quickly. Selection is possible since elements are there but just invisible and when webgl textures were animated we can lazily update DOM positions without affecting performance a lot. Is there a repo for your terminal?
thecatspaw 12y ago
it looks blurry. does it support retina displays?
methyl 12y ago
So we have browser in the browser, we have to go deeper...
- PixelsCommander 12y ago
  It is basicaly not. Just converting HTML to texture with some tricky proxying. The reason is to be able to do that http://pixelscommander.com/polygon/htmlgl/demo/filters.html http://pixelscommander.com/polygon/htmlgl/demo/filters.html
  - MrDosu 12y ago
    What he means is that is exactly what the browser does already. It's just slower because it handles more of the standard. It rasterizes the DOM.
    - PixelsCommander 12y ago
      Browser rasterizes based on it`s assumptions and you cant control it completely which is a bottleneck for performance optimization. Also how would you apply displacement filter on that content?
    - methyl 12y ago
      It's also faster because it's native, not JavaScript.
outworlder 12y ago
Now we need a WebGL demoscene.
- PixelsCommander 12y ago
  It is already there https://www.chromeexperiments.com/webgl https://www.chromeexperiments.com/webgl , but it starts to be even more exciting if you think about effects which could be applied to web sites and HTML content... Bumb mapping, reflections, motion blur, elastic elements when dragging. Whole bunch of shaders https://www.shadertoy.com/browse https://www.shadertoy.com/browse
- theandrewbailey 12y ago
  There is. It's been around since WebGL was a thing. http://www.pouet.net/prodlist.php?platform[]=JavaScript&page=1 http://www.pouet.net/prodlist.php?platform[]=JavaScript&page...
  - PixelsCommander 12y ago
    Cool, thx
- MrDosu 12y ago
  Demoscene is not about flashy graphics. It's about doing something beautiful with code (this includes the way the code uses the machine to do things that go beyond, like mode 13h).
aout 12y ago
Wait wait wait... Handling textures via CG Buffers is quite fast you are right and you can basically do whatever you want in terms of image manipulation using the shaders but you'll lose efficiency as soon as you introduce complex picking (text selection for example) and / or computations (aliasing etc...) between JS and your pseudo-DOM. In the end the only difference you'll have compared to the real browser renderer is that you do less computations from CG(GL) to RAM (JS), hence the performance. You can check this very old project of mine where we tried to link DOM and WebGL Nodes: https://github.com/aout/SAGE https://github.com/aout/SAGE edit: just saw the repo wasn't entirely up to date. Done now.
- bsenftner 12y ago
  Could you speak a bit more on the issues you encountered?
  - aout 12y ago
    Well, your browser is already GPU-accelerated. What makes it slow is the process of making GPU-memory accessible to your JavaScript. An example of that is drawing a DIV and applying a CSS 3D Transform to it. By doing so you'll modify it's display on the screen so you'll need to recompute it's actual bounding box. If you compute the BBox on the GPU and never access it anywhere else, everything is fine but as soon as you have to use it in JS you're screwed because you'll have to transfer data from your GPU to your RAM. Doing so at 60fps is very expensive, then you'll take a performance hit from JavaScript being usually slower than C/C++. That's not the only problem you'll have, text rendering is probably the biggest one. As you might know, textures are rendered using memory friendly algorithms. To ensure maximum readability and quality you'll have to (1) use a lot of memory and / or (2) apply some advanced filtering so your texture doesn't lose quality. Those techniques are quite hard to implement if you're not a 3D programmer (just check what happens if you try to rotate text in CSS and select it) but more importantly you'll find yourself reinventing the wheel.
    - onion2k 12y ago
      If you were happy to ignore hover, you'd only need to compute the bounding box when there's an event like a click.
bsenftner 12y ago
Really great work. I've had in the back of my mind that this was possible, but now you've gone and done it, and quite well! I'm curious if there would be any conflict with usage of Three.js on the same site? Could they end up clobbering each other's textures? (I've not gotten into webgl's texture memory management, so that question is a stab in the dark.)
- PixelsCommander 12y ago
  I would not expect any conflicts there since they are different canvases and textures uploaded just as files. You may ask mat@goodboydigital.com for more details.
heldrida 12y ago
Holy cow! This is a great idea : D the responsiveness is a bit sloppy but it's really good you guys have it working! haha really cool : D
- PixelsCommander 12y ago
  Thanks! We are working on improving responsiveness a bit. Will be better.
designml 12y ago
Ahh Nice! I was going to start working on something similar to this.
- PixelsCommander 12y ago
  Come on! We can do much more together =) Still so many WOW things to implement...
  - designml 12y ago
    Haha yea, I am going to delve into your code and see if I can contribute. But nice work! Your site is probably getting hammered now with the traffic but I am going to come back and check it out.
danbruc 12y ago
This was at least kind of possible (not sure if it worked only for images or also other elements) with Internet Explorer 4 [1] in 1997, almost two decades ago. It was obviously non-standard. [1] https://msdn.microsoft.com/en-us/library/ms532849.aspx https://msdn.microsoft.com/en-us/library/ms532849.aspx
- cordite 12y ago
  Although non-standard, Microsoft sure did several novel things back in the day here. Then they decided not to do the actual standards correctly and held a lot of things back since nobody updated these things. On the topic of Microsoft and the web, ActiveX gets a lot of bad rep (and for good reason), though it seems like they were trying something akin to web components back then. It worked better in actual applications than the web though.
kolodny 12y ago
fiddle: http://jsfiddle.net/409gxzm6/ http://jsfiddle.net/409gxzm6/
- bshimmin 12y ago
  The text is blurred on my retina MacBook Pro. (And not selectable, as others have mentioned.)
  - PixelsCommander 12y ago
    Yes, there is an issue on that. https://github.com/PixelsCommander/HTML-GL/issues/11 https://github.com/PixelsCommander/HTML-GL/issues/11 I d like to fix it before going public but HTML5WEEKLY made announcement without notice, so everybody sees know that bug =( As for selection - it is selectable in it`s bounding box, but selection is not highlighted yet.
    - deleted 12y ago
      [deleted]
      - PixelsCommander 12y ago
        Is seems that rasterization happend before images loaded. Do not observe this on any devices accessible for me. Is there any specificity on system you tried it?
kluck 12y ago
Recreating existing desktop GUI frameworks one useless HTML/JS library at a time.
- PixelsCommander 12y ago
  Come on http://pixelscommander.com/polygon/htmlgl/demo/filters.html http://pixelscommander.com/polygon/htmlgl/demo/filters.html
  - deleted 12y ago
    [deleted]
- MrDosu 12y ago
  I don't get why people do this without looking at least once at all the existing open source html rendering implementations. Also, css shaders.
  - PixelsCommander 12y ago
    What is the browser support for CSS shaders? =)
    - cturhan 12y ago
      Just chrome and Firefox canary I guess. But webgl is supports by all modern browsers. I can even see nicely rendered page on my windows phone with IE11 mobile installed.
- angersock 12y ago
  Massively underrated post, honestly. I wonder what exactly the use of this is, beyond Compiz for web pages. What's next, jiggly divs? :P moron4hire made a good point about letting devs pick the layout engine, but I am not sure we want to ignore all the nice features browsers give us here.
bsenftner 12y ago
Would forms and input fields still work? Could one push their wysiwyg rich text editor into this? (I'm thinking game / VR content where an in-3D-world web browser on some in-3D-world device screen is fully operational.)
- PixelsCommander 12y ago
  It depends on how far it will go. At the moment there is a plan how to do that, but not enough time to implement... You may use it for editor, but keep in mind that text itself would be sent to GPU every time it updates. Anyhow you may ping me in skype lp_funky if interested in doing this, would be glad to help.
perdunov 12y ago
As far as I understand, this is roughly how iOS UI works (UIView - CALayer). Obviously, this can be done at the browser engine level. I have also tried to do this in my pet UI engine, but found out that it was tricky to figure out caching rules to avoid memory blowup and performance degradation for all possible cases.
- PixelsCommander 12y ago
  It is done but there is no control over rasterization and no possibility to add filters as in the demo http://pixelscommander.com/polygon/htmlgl/demo/filters.html http://pixelscommander.com/polygon/htmlgl/demo/filters.html
  - perdunov 12y ago
    Kudos for the smart solution. This approach has proven itself very well in iOS, in fact, it was the absolute best mobile animation technology for a long time. Actually, the older versions of iOS used software rasterization with hardware accelerated bitmap caching and it worked smoothly on the original iPhone.
cturhan 12y ago
What if we merge it with React and use its virtual Dom management?
- PixelsCommander 12y ago
  I think could be nice. There is an intention to create React-GL, but nothing serious yet. All you basically need is to call something like new GLElement(this.getDOMNode()). Or how is it in 0.13?...
  - cturhan 12y ago
    Actually there is an implementation called react-canvas does the same thing on canvas. Flipboard uses it on mobile website and it has a great performance even for mobile.
phn 12y ago
Make it feature complete and you'll get the same speed the browser has. If we're going to build a new rendering engine for the web, maybe we could try to create something nicer than HTML and CSS, whose only advantage at the present is the number of developers familiar with it. I know I wouldn't miss them.
- emodendroket 12y ago
  What is there that's so much better?
  - aout 12y ago
    Because you could do something easier to understand in terms of 3D for a very simple use case and find a generic use for it.
    - emodendroket 12y ago
      I'm assuming this is not in the right place because I don't understand how it answers my question.
    - aout 12y ago
      Your browser is slow when applying transform to DOM elements because it has to translate everything 3D in terms of JavaScript and DOM. If you want to manipulate images and elements effectively in 3D then you have to learn matrix computations, quaternions and stuff which is horrible for the common web developer. I'm saying that if you offer a new approach that could mix HTML/CSS and encapsulate those complex 3D concepts it would be interesting.
  - moron4hire 12y ago
    There really isn't anything "better". HTML isn't great, but it's all we got right now. le sigh.
    - pjmlp 12y ago
      I am quite happy to have moved back to the native world.
moron4hire 12y ago
This creates an interesting change in how applications are deployed to users. Instead of the user choosing the HTML rendering engine, the developer now gets to choose it. Instead of having to design sites with multiple rendering engines in mind, this makes it possible to manage only one. And it's not like the user cares that content is being rendered by Firefox or Chrome or whatever, the user just cares to see the page, leaving the selection of the actual rendering engine only of concern to the developer. I think that's important enough to warrant going through the paces and implementing this. Don't listen to the naysayers. Reinvent wheels. The wheels we currently have largely suck.
- perdunov 12y ago
  C++ with asm.js + WebGL effectively bring back desktop programming to the web.
  - moron4hire 12y ago
    That is so not even close to a good way to build applications. I mean, I really can't think of anything more painful right now. Other than, maybe being asked to make a modern web application on classic ASP.
pierrec 12y ago
Very cool. This could be useful for some applications, but I don't see it becoming a thing for general use cases unless it's implemented and exposed directly by the browsers. Even then, the main problem is that the internet is still mostly text, and if you can't implement or access font hinting, your text will be blurry and ugly on any display that isn't ultra-high DPI. You can't really render text to a texture and then manipulate that texture with sub-pixel precision. It must be done the other way around: text rendering must be done last, and with the help of a hinting library so it will look sharp and readable.
- PixelsCommander 12y ago
  There is an intent to make rasterization native http://pixelscommander.com/en/javascript/state-of-html-content-rasterization-draw-html-to-canvas-image/ http://pixelscommander.com/en/javascript/state-of-html-conte...
SoapSeller 12y ago
This project(at least for me) is a little bit misleading. Because it isn't rendering HTML using WebGL. It using html2canvas[0] to rasterize the browser rendering into a canvas, upload it to WebGL, apply effects and patch-back events(i.e. mouse clicks) back to the hidden browser dom elements. (On the other side, font hinting and such are not really a problem) Implementing full UI framework over WebGL has it merits, and hopefully someone will make a useful(and not html+css based) one some day. [0] https://github.com/niklasvh/html2canvas https://github.com/niklasvh/html2canvas
- Polarity 12y ago
  u know http://famo.us http://famo.us ?
  - kowdermeister 12y ago
    Famous is CSS based, not WebGL
    - liviu 12y ago
      Actually it has WebGL renderer. Famo.us is the only JavaScript framework that includes an open source 3D layout engine fully integrated with a 3D physics animation engine that can render to DOM, Canvas, or WebGL.
      - argonaut 12y ago
        Actually it doesn't. Have you actually used famo.us? You do realize you're just quoting the website copy. Famo.us doesn't have WebGL rendering yet.
        jiyinyiyong 12y ago
        They've shown demos of WebGL renderer. It's called "Mixed mode" as I can remember. But it's probably not released yet.
  - 12y ago
josephmx 12y ago
Very minor bug on the demo: The alert on click reads "clicked X" (eg, "Clicked Avatar") on all of the titles except for Quantum of Solace
slaction 12y ago
"I really wish I could use bump mapping on this div" - No one ever
curiously 12y ago
this idea is so crazy it just might work but need to see some more examples. one might be a crazy heavy SPA or javascript webpage that lags and show it through HTMLGL. this really could go somewhere, the idea is solid but it might take some work to actually deliver, a constant fps web.
- PixelsCommander 12y ago
  Yes, the only bottleneck here is rasterization which we are trying to solve by making native Rasterization API live. You can read about here http://pixelscommander.com/en/javascript/state-of-html-content-rasterization-draw-html-to-canvas-image/ http://pixelscommander.com/en/javascript/state-of-html-conte...
mandeepj 12y ago
Then all the hard work that flipboard did to achieve 60 fps rendering speed was not required? Reference - https://news.ycombinator.com/item?id=9029159 https://news.ycombinator.com/item?id=9029159

jeremiep 12y ago

It looks great, but I don't like the fact that I can't select the text anymore!

PixelsCommander 12y ago
It can be selected at same bounding box DOM node have and the selection will not be highlighted at the moment, but we will fix that.
- riskable 12y ago
  If you can get text selection (and copy/paste) working please post how you did it. I wrote Gate One which is a web-based terminal emulator. Right now I have to go through great pains to ensure that text being rendered to the screen happens in a performant way while still allowing for copy & paste functionality. It also has some features that will highlight text that you select with your mouse and other text formatting stuff. I've experimented with canvas in the past to see if it could improve the performance of, say, a terminal that updates very quickly but it ultimately ended up being just as slow as the regular DOM because of all the extra code that had to be running in order to keep the hidden buffer in sync with what was displayed to the user. I'd be curious to know how the performance of WebGL compares to the (accelerated) canvas.
  - PixelsCommander 12y ago
    Performance is much better if translation / scaling / opacity / rotation are used or shaders ofcourse. If image content redraws by CPU it sucks. Basically it is what GPU can do quickly. Selection is possible since elements are there but just invisible and when webgl textures were animated we can lazily update DOM positions without affecting performance a lot. Is there a repo for your terminal?

thecatspaw 12y ago

it looks blurry. does it support retina displays?

methyl 12y ago

So we have browser in the browser, we have to go deeper...

PixelsCommander 12y ago
It is basicaly not. Just converting HTML to texture with some tricky proxying. The reason is to be able to do that http://pixelscommander.com/polygon/htmlgl/demo/filters.html http://pixelscommander.com/polygon/htmlgl/demo/filters.html
- MrDosu 12y ago
  What he means is that is exactly what the browser does already. It's just slower because it handles more of the standard. It rasterizes the DOM.
  - PixelsCommander 12y ago
    Browser rasterizes based on it`s assumptions and you cant control it completely which is a bottleneck for performance optimization. Also how would you apply displacement filter on that content?
  - methyl 12y ago
    It's also faster because it's native, not JavaScript.

outworlder 12y ago

Now we need a WebGL demoscene.

PixelsCommander 12y ago
It is already there https://www.chromeexperiments.com/webgl https://www.chromeexperiments.com/webgl , but it starts to be even more exciting if you think about effects which could be applied to web sites and HTML content... Bumb mapping, reflections, motion blur, elastic elements when dragging. Whole bunch of shaders https://www.shadertoy.com/browse https://www.shadertoy.com/browse
theandrewbailey 12y ago
There is. It's been around since WebGL was a thing. http://www.pouet.net/prodlist.php?platform[]=JavaScript&page=1 http://www.pouet.net/prodlist.php?platform[]=JavaScript&page...
- PixelsCommander 12y ago
  Cool, thx
MrDosu 12y ago
Demoscene is not about flashy graphics. It's about doing something beautiful with code (this includes the way the code uses the machine to do things that go beyond, like mode 13h).

aout 12y ago

Wait wait wait... Handling textures via CG Buffers is quite fast you are right and you can basically do whatever you want in terms of image manipulation using the shaders but you'll lose efficiency as soon as you introduce complex picking (text selection for example) and / or computations (aliasing etc...) between JS and your pseudo-DOM. In the end the only difference you'll have compared to the real browser renderer is that you do less computations from CG(GL) to RAM (JS), hence the performance. You can check this very old project of mine where we tried to link DOM and WebGL Nodes: https://github.com/aout/SAGE https://github.com/aout/SAGE edit: just saw the repo wasn't entirely up to date. Done now.

bsenftner 12y ago
Could you speak a bit more on the issues you encountered?
- aout 12y ago
  Well, your browser is already GPU-accelerated. What makes it slow is the process of making GPU-memory accessible to your JavaScript. An example of that is drawing a DIV and applying a CSS 3D Transform to it. By doing so you'll modify it's display on the screen so you'll need to recompute it's actual bounding box. If you compute the BBox on the GPU and never access it anywhere else, everything is fine but as soon as you have to use it in JS you're screwed because you'll have to transfer data from your GPU to your RAM. Doing so at 60fps is very expensive, then you'll take a performance hit from JavaScript being usually slower than C/C++. That's not the only problem you'll have, text rendering is probably the biggest one. As you might know, textures are rendered using memory friendly algorithms. To ensure maximum readability and quality you'll have to (1) use a lot of memory and / or (2) apply some advanced filtering so your texture doesn't lose quality. Those techniques are quite hard to implement if you're not a 3D programmer (just check what happens if you try to rotate text in CSS and select it) but more importantly you'll find yourself reinventing the wheel.
  - onion2k 12y ago
    If you were happy to ignore hover, you'd only need to compute the bounding box when there's an event like a click.

bsenftner 12y ago

Really great work. I've had in the back of my mind that this was possible, but now you've gone and done it, and quite well! I'm curious if there would be any conflict with usage of Three.js on the same site? Could they end up clobbering each other's textures? (I've not gotten into webgl's texture memory management, so that question is a stab in the dark.)

PixelsCommander 12y ago
I would not expect any conflicts there since they are different canvases and textures uploaded just as files. You may ask mat@goodboydigital.com for more details.

heldrida 12y ago

Holy cow! This is a great idea : D the responsiveness is a bit sloppy but it's really good you guys have it working! haha really cool : D

PixelsCommander 12y ago
Thanks! We are working on improving responsiveness a bit. Will be better.

designml 12y ago

Ahh Nice! I was going to start working on something similar to this.

PixelsCommander 12y ago
Come on! We can do much more together =) Still so many WOW things to implement...
- designml 12y ago
  Haha yea, I am going to delve into your code and see if I can contribute. But nice work! Your site is probably getting hammered now with the traffic but I am going to come back and check it out.

danbruc 12y ago

This was at least kind of possible (not sure if it worked only for images or also other elements) with Internet Explorer 4 [1] in 1997, almost two decades ago. It was obviously non-standard. [1] https://msdn.microsoft.com/en-us/library/ms532849.aspx https://msdn.microsoft.com/en-us/library/ms532849.aspx

cordite 12y ago
Although non-standard, Microsoft sure did several novel things back in the day here. Then they decided not to do the actual standards correctly and held a lot of things back since nobody updated these things. On the topic of Microsoft and the web, ActiveX gets a lot of bad rep (and for good reason), though it seems like they were trying something akin to web components back then. It worked better in actual applications than the web though.

kolodny 12y ago

fiddle: http://jsfiddle.net/409gxzm6/ http://jsfiddle.net/409gxzm6/

bshimmin 12y ago
The text is blurred on my retina MacBook Pro. (And not selectable, as others have mentioned.)
- PixelsCommander 12y ago
  Yes, there is an issue on that. https://github.com/PixelsCommander/HTML-GL/issues/11 https://github.com/PixelsCommander/HTML-GL/issues/11 I d like to fix it before going public but HTML5WEEKLY made announcement without notice, so everybody sees know that bug =( As for selection - it is selectable in it`s bounding box, but selection is not highlighted yet.
  - deleted 12y ago
    [deleted]
    - PixelsCommander 12y ago
      Is seems that rasterization happend before images loaded. Do not observe this on any devices accessible for me. Is there any specificity on system you tried it?

kluck 12y ago

Recreating existing desktop GUI frameworks one useless HTML/JS library at a time.

PixelsCommander 12y ago
Come on http://pixelscommander.com/polygon/htmlgl/demo/filters.html http://pixelscommander.com/polygon/htmlgl/demo/filters.html
- deleted 12y ago
  [deleted]
MrDosu 12y ago
I don't get why people do this without looking at least once at all the existing open source html rendering implementations. Also, css shaders.
- PixelsCommander 12y ago
  What is the browser support for CSS shaders? =)
  - cturhan 12y ago
    Just chrome and Firefox canary I guess. But webgl is supports by all modern browsers. I can even see nicely rendered page on my windows phone with IE11 mobile installed.
angersock 12y ago
Massively underrated post, honestly. I wonder what exactly the use of this is, beyond Compiz for web pages. What's next, jiggly divs? :P moron4hire made a good point about letting devs pick the layout engine, but I am not sure we want to ignore all the nice features browsers give us here.

bsenftner 12y ago

Would forms and input fields still work? Could one push their wysiwyg rich text editor into this? (I'm thinking game / VR content where an in-3D-world web browser on some in-3D-world device screen is fully operational.)

PixelsCommander 12y ago
It depends on how far it will go. At the moment there is a plan how to do that, but not enough time to implement... You may use it for editor, but keep in mind that text itself would be sent to GPU every time it updates. Anyhow you may ping me in skype lp_funky if interested in doing this, would be glad to help.

perdunov 12y ago

As far as I understand, this is roughly how iOS UI works (UIView - CALayer). Obviously, this can be done at the browser engine level. I have also tried to do this in my pet UI engine, but found out that it was tricky to figure out caching rules to avoid memory blowup and performance degradation for all possible cases.

PixelsCommander 12y ago
It is done but there is no control over rasterization and no possibility to add filters as in the demo http://pixelscommander.com/polygon/htmlgl/demo/filters.html http://pixelscommander.com/polygon/htmlgl/demo/filters.html
- perdunov 12y ago
  Kudos for the smart solution. This approach has proven itself very well in iOS, in fact, it was the absolute best mobile animation technology for a long time. Actually, the older versions of iOS used software rasterization with hardware accelerated bitmap caching and it worked smoothly on the original iPhone.

cturhan 12y ago

What if we merge it with React and use its virtual Dom management?

PixelsCommander 12y ago
I think could be nice. There is an intention to create React-GL, but nothing serious yet. All you basically need is to call something like new GLElement(this.getDOMNode()). Or how is it in 0.13?...
- cturhan 12y ago
  Actually there is an implementation called react-canvas does the same thing on canvas. Flipboard uses it on mobile website and it has a great performance even for mobile.

phn 12y ago

Make it feature complete and you'll get the same speed the browser has. If we're going to build a new rendering engine for the web, maybe we could try to create something nicer than HTML and CSS, whose only advantage at the present is the number of developers familiar with it. I know I wouldn't miss them.

emodendroket 12y ago
What is there that's so much better?
- aout 12y ago
  Because you could do something easier to understand in terms of 3D for a very simple use case and find a generic use for it.
  - emodendroket 12y ago
    I'm assuming this is not in the right place because I don't understand how it answers my question.
  - aout 12y ago
    Your browser is slow when applying transform to DOM elements because it has to translate everything 3D in terms of JavaScript and DOM. If you want to manipulate images and elements effectively in 3D then you have to learn matrix computations, quaternions and stuff which is horrible for the common web developer. I'm saying that if you offer a new approach that could mix HTML/CSS and encapsulate those complex 3D concepts it would be interesting.
- moron4hire 12y ago
  There really isn't anything "better". HTML isn't great, but it's all we got right now. le sigh.
  - pjmlp 12y ago
    I am quite happy to have moved back to the native world.

moron4hire 12y ago

This creates an interesting change in how applications are deployed to users. Instead of the user choosing the HTML rendering engine, the developer now gets to choose it. Instead of having to design sites with multiple rendering engines in mind, this makes it possible to manage only one. And it's not like the user cares that content is being rendered by Firefox or Chrome or whatever, the user just cares to see the page, leaving the selection of the actual rendering engine only of concern to the developer. I think that's important enough to warrant going through the paces and implementing this. Don't listen to the naysayers. Reinvent wheels. The wheels we currently have largely suck.

perdunov 12y ago
C++ with asm.js + WebGL effectively bring back desktop programming to the web.
- moron4hire 12y ago
  That is so not even close to a good way to build applications. I mean, I really can't think of anything more painful right now. Other than, maybe being asked to make a modern web application on classic ASP.

pierrec 12y ago

Very cool. This could be useful for some applications, but I don't see it becoming a thing for general use cases unless it's implemented and exposed directly by the browsers. Even then, the main problem is that the internet is still mostly text, and if you can't implement or access font hinting, your text will be blurry and ugly on any display that isn't ultra-high DPI. You can't really render text to a texture and then manipulate that texture with sub-pixel precision. It must be done the other way around: text rendering must be done last, and with the help of a hinting library so it will look sharp and readable.

PixelsCommander 12y ago
There is an intent to make rasterization native http://pixelscommander.com/en/javascript/state-of-html-content-rasterization-draw-html-to-canvas-image/ http://pixelscommander.com/en/javascript/state-of-html-conte...

SoapSeller 12y ago

This project(at least for me) is a little bit misleading. Because it isn't rendering HTML using WebGL. It using html2canvas[0] to rasterize the browser rendering into a canvas, upload it to WebGL, apply effects and patch-back events(i.e. mouse clicks) back to the hidden browser dom elements. (On the other side, font hinting and such are not really a problem) Implementing full UI framework over WebGL has it merits, and hopefully someone will make a useful(and not html+css based) one some day. [0] https://github.com/niklasvh/html2canvas https://github.com/niklasvh/html2canvas

Polarity 12y ago
u know http://famo.us http://famo.us ?
- kowdermeister 12y ago
  Famous is CSS based, not WebGL
  - liviu 12y ago
    Actually it has WebGL renderer. Famo.us is the only JavaScript framework that includes an open source 3D layout engine fully integrated with a 3D physics animation engine that can render to DOM, Canvas, or WebGL.
    - argonaut 12y ago
      Actually it doesn't. Have you actually used famo.us? You do realize you're just quoting the website copy. Famo.us doesn't have WebGL rendering yet.
      - jiyinyiyong 12y ago
        They've shown demos of WebGL renderer. It's called "Mixed mode" as I can remember. But it's probably not released yet.
- 12y ago

josephmx 12y ago

Very minor bug on the demo: The alert on click reads "clicked X" (eg, "Clicked Avatar") on all of the titles except for Quantum of Solace

slaction 12y ago

"I really wish I could use bump mapping on this div" - No one ever

curiously 12y ago

this idea is so crazy it just might work but need to see some more examples. one might be a crazy heavy SPA or javascript webpage that lags and show it through HTMLGL. this really could go somewhere, the idea is solid but it might take some work to actually deliver, a constant fps web.

PixelsCommander 12y ago
Yes, the only bottleneck here is rasterization which we are trying to solve by making native Rasterization API live. You can read about here http://pixelscommander.com/en/javascript/state-of-html-content-rasterization-draw-html-to-canvas-image/ http://pixelscommander.com/en/javascript/state-of-html-conte...

mandeepj 12y ago

Then all the hard work that flipboard did to achieve 60 fps rendering speed was not required? Reference - https://news.ycombinator.com/item?id=9029159 https://news.ycombinator.com/item?id=9029159