4 ms·
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 t
by 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 agoCould you speak a bit more on the issues you encountered?
- aout 12y agoWell, 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 agoIf you were happy to ignore hover, you'd only need to compute the bounding box when there's an event like a click.
- aout 12y agoTrue, but picking is only one pass of rendering (and a pretty fast one as you can see here: https://github.com/aout/SAGE/tree/Multipass/Sage3D/Resources/Shaders/picking https://github.com/aout/SAGE/tree/Multipass/Sage3D/Resources...).
- PixelsCommander 12y agoNice, we may use it as a renderer for HTML GL. Shaders and fast rendering wirth it I believe. Try the demo in the bottom http://htmlgl.com/ http://htmlgl.com/
- aout 12y agoI tried the demo of course and I thought you did a great job. I'm not saying you should abandon the project because of performance issues you'll encounter but rather focus on simplicity with clear boundaries. Again, go for it! (but don't go too far)
- PixelsCommander 12y agoThank you. Agree, simplicity is what it is created for, will keep it that way.
- aout 12y agoJust updated the repo with multipass rendering including picking and lights. Might interest you.
- danjayh 12y agoI like the concept for graphics-heavy pages, but for any text-oriented page ... well, any website that didn't support highlighting (which I use to keep track of where I am on a page) and that didn't re-render when zooming (absolutely necessary for high-res displays, where a page might show up tiny and need to be re-scaled) would be a website that I didn't stay at for very long.