5 ms·

Like this? http://jsfiddle.net/eymAS/2/ http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web compone

by just2n 13y ago

Like this? http://jsfiddle.net/eymAS/2/ http://jsfiddle.net/eymAS/2/ The DOM is faster than almost everyone believes. It's not 2001 anymore, guys. Web components solve a lot of major problems, but it has little to do with DOM/CSS performance and more to do with encapsulation (ie, so your CSS/HTML/JS don't break a component). DocumentFragments and insertAdjacentHTML solved more performance problems for the DOM than most other API changes have, and smarter compositing/painting algorithms in browsers (along with hardware acceleration) have made it possible to do some pretty ridiculous stuff.

ChuckMcM 13y ago
Man, that is just scary fast :-)
- krebby 13y ago
  It should be, it's hardware-accelerated (take a look at the translate3d hack) Paul Irish did a good writeup here: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/ http://www.paulirish.com/2012/why-moving-elements-with-trans...
  - just2n 13y ago
    Yep. Here's a version without using 3d (no layers generated for the followers): http://jsfiddle.net/eymAS/29/ http://jsfiddle.net/eymAS/29/ The layout/composition/painting etc is taking roughly 5x longer now. Chrome is smart enough to do it all just once, though, so it's still relatively performant.
fhd2 13y ago
Here's a version that's not Chrome-only: http://jsfiddle.net/eymAS/21/ http://jsfiddle.net/eymAS/21/ I've been wondering why I keep hearing that the DOM is supposed to be slow. Don't people mean to say that rendering (i.e. mostly CSS) is slow? This fiddle is certainly not doing much with the DOM except setting style attributes.
- just2n 13y ago
  People generally mean their manipulation of DOM is effectively slow. That's a perfectly accurate statement, but the problem is calling the DOM slow as a result. The real culprit is often that doing stupid things with the DOM cause style recalcs, reflows, layouts, compositing, painting, etc. Those are all comparatively expensive.
- vladmoz 13y ago
  The problem with the DOM is not that it's intrinsically slow, but that it's very easy to do slow things with it inadvertently. There are often N different ways to do things, due to the evolution of HTML. The newer approaches tend to be designed with things like GPU acceleration in mind (e.g. CSS transforms), whereas older methods often had lots of heavy interactions and computations because they weren't expected to be used dynamically. Just like optimizing any software takes skill and knowledge, so too does writing HTML, whether dynamic or not. Tools for understanding what's going on with the DOM and with dynamic HTML are slowly becoming available as well, which will help with this.
roel_v 13y ago
So now we're going to say that in 2013 it is impressive that 160 rectangles can follow a mouse cursor? I see the advantages of client/server applications (as they used to be called), and presumably js/css apps will continue to get faster and asymptotically approach their client-only functional equivalents, but there is a thing about a hammer and all problems looking like nails that springs to mind when I see people claim that moving 160 rectangles in 16 ms / frame is 'scary fast'...
- just2n 13y ago
  The parent's comment was that it is essentially infeasible to have a single div follow the cursor due to performance issues with the DOM. The fiddle includes 160 divs and opacity to demonstrate that that claim is false. There's an awful lot of red herring going on in your post. It sounds like you have some problems with the web, but they most certainly aren't relevant to this discussion.
  - roel_v 13y ago
    Oh I have no problems with the web, it has been providing me with a good living for well over a decade. Maybe that's my problem - that I remember the times when things that are being described now as 'great' or 'fast' were solved already, and my frustration is that instead of moving forward, we now have to repeat the last decade except with js/css before we can really start to innovate again. Unreal engine in the browser? Seriously? Because of what - because it's easier to update people's clients when they download it again every time they visit your website? We had web launchers and auto-updating that solved everything the web brings as an advantage over desktop applications (in the use cases that require fast graphics, i.e. not CRUD line of business applications) years ago. The elephant in the room here is that people want to push web applications because it's easier to make money from them, and you can make more of it, over a longer time. Look, I do it too, I know that the web beats the pants off client-only software from a business point of view. But let's call a spade a spade and not tip toe around it with bullshit pseudo-arguments like 'ease of deployability' and 'social sharing' and 'portability' and 'platform-agnosticity'.
    - 13y ago
ux-app 13y ago
That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fps performance. Would be great if Chrome had this option off by default.
- exDM69 13y ago
  > Would be great if Chrome had this option off by default. Disabling Vsync causes page tearing artifacts (https://en.wikipedia.org/wiki/Page_tearing https://en.wikipedia.org/wiki/Page_tearing). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.
  - ux-app 13y ago
    isn't tearing preferable to input lag? As I mentioned, with v-sync on there is a very noticeable rubber-banding effect, with it off the result is (perceptually) far smoother. >It [vsync] should always be enabled by default Not sure about this. Surely the goal is to maximize perceived performance not 'correctness' (where correctness in this context is defined as each frame being fully drawn before the next one starts).
    - exDM69 13y ago
      > isn't tearing preferable to input lag? In a properly written app, vsync should not cause input lag despite gamer superstitions. But there are lots of not-properly written apps where this is a problem. WebGL / Chrome should solve the problem in some other way, not disabling vsync. Or using adaptive vsync if available as a workaround. The culprit here might be the ANGLE OpenGLES2-on-D3D9 wrapper that Chrome uses, which is notoriously slow on synchronous operations like vsync, glGetError or glFinish.
- just2n 13y ago
  That was just caused by me not processing input properly. I've set up a proper rendering loop here and now only render the most recent mouse position on each frame: http://jsfiddle.net/eymAS/84/ http://jsfiddle.net/eymAS/84/ It's better, but still limited to 60fps, and since I render to the state at 0s, the worst delay we can see is ~16.6ms + rendering time.
spyder 13y ago
For me the movement is smooth but it still lags behind the mouse with 10-20 px. The Firefox version of the demo has a little less lag but still looks disconnected from the mouse when moved.
cpleppert 13y ago
The problem is that the DOM is a hard upper limit on performance compared to what the performance of an unsafe language (asm.js) is. It is massively complex because it must perform every UI task in the browser and simply moving around DIVs doesn't give you a feel for its the performance in complex scenarios. If you think about how native applications perform and then imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction you get a sense of what the problem is. There is simply no way to get the DOM to do something it wasn't designed to do, which is to be a document display interface and not a general graphical user interface. You have to clobber together a lot of interactions to get the desired behavior and not only does this increase the overhead for both your program and the DOM you are going to hit cases where the DOM isn't optimized. This doesn't mean that the DOM is inherently slow. If you tried to offload the UI work onto javascript you wouldn't get the performance benefit of doing that on Asm.js or NACL. You really need unsafe code to solve this problem. Asm.js and NACL are only useful if you are going to do this; targeting the Canvas and WebGL gives you the ability to do that.
- BrendanEich 13y ago
  asm.js is not an "unsafe language". /be
- vladmoz 13y ago
  What you describe -- "imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction" -- is exactly how Firefox is built. The desktop Firefox UI is all DOM elements (not HTML, but still the same underlying DOM code). Hovering over a toolbar button or a tab causes a CSS style rule for a :hover effect to be applied. Opening a new tab uses CSS animation for the transition. Moving tabs around manipulates the DOM and moves the tab elements (which are themselves composed of images, labels, etc.). And yet, the Firefox UI is plenty snappy -- yes, you can argue that there are slowdowns and issues that need to be fixed, but no more or less than in many "native" apps.

by just2n 13y ago

ChuckMcM 13y ago

Man, that is just scary fast :-)

krebby 13y ago
It should be, it's hardware-accelerated (take a look at the translate3d hack) Paul Irish did a good writeup here: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/ http://www.paulirish.com/2012/why-moving-elements-with-trans...
- just2n 13y ago
  Yep. Here's a version without using 3d (no layers generated for the followers): http://jsfiddle.net/eymAS/29/ http://jsfiddle.net/eymAS/29/ The layout/composition/painting etc is taking roughly 5x longer now. Chrome is smart enough to do it all just once, though, so it's still relatively performant.

fhd2 13y ago

Here's a version that's not Chrome-only: http://jsfiddle.net/eymAS/21/ http://jsfiddle.net/eymAS/21/ I've been wondering why I keep hearing that the DOM is supposed to be slow. Don't people mean to say that rendering (i.e. mostly CSS) is slow? This fiddle is certainly not doing much with the DOM except setting style attributes.

just2n 13y ago
People generally mean their manipulation of DOM is effectively slow. That's a perfectly accurate statement, but the problem is calling the DOM slow as a result. The real culprit is often that doing stupid things with the DOM cause style recalcs, reflows, layouts, compositing, painting, etc. Those are all comparatively expensive.
vladmoz 13y ago
The problem with the DOM is not that it's intrinsically slow, but that it's very easy to do slow things with it inadvertently. There are often N different ways to do things, due to the evolution of HTML. The newer approaches tend to be designed with things like GPU acceleration in mind (e.g. CSS transforms), whereas older methods often had lots of heavy interactions and computations because they weren't expected to be used dynamically. Just like optimizing any software takes skill and knowledge, so too does writing HTML, whether dynamic or not. Tools for understanding what's going on with the DOM and with dynamic HTML are slowly becoming available as well, which will help with this.

roel_v 13y ago

So now we're going to say that in 2013 it is impressive that 160 rectangles can follow a mouse cursor? I see the advantages of client/server applications (as they used to be called), and presumably js/css apps will continue to get faster and asymptotically approach their client-only functional equivalents, but there is a thing about a hammer and all problems looking like nails that springs to mind when I see people claim that moving 160 rectangles in 16 ms / frame is 'scary fast'...

just2n 13y ago
The parent's comment was that it is essentially infeasible to have a single div follow the cursor due to performance issues with the DOM. The fiddle includes 160 divs and opacity to demonstrate that that claim is false. There's an awful lot of red herring going on in your post. It sounds like you have some problems with the web, but they most certainly aren't relevant to this discussion.
- roel_v 13y ago
  Oh I have no problems with the web, it has been providing me with a good living for well over a decade. Maybe that's my problem - that I remember the times when things that are being described now as 'great' or 'fast' were solved already, and my frustration is that instead of moving forward, we now have to repeat the last decade except with js/css before we can really start to innovate again. Unreal engine in the browser? Seriously? Because of what - because it's easier to update people's clients when they download it again every time they visit your website? We had web launchers and auto-updating that solved everything the web brings as an advantage over desktop applications (in the use cases that require fast graphics, i.e. not CRUD line of business applications) years ago. The elephant in the room here is that people want to push web applications because it's easier to make money from them, and you can make more of it, over a longer time. Look, I do it too, I know that the web beats the pants off client-only software from a business point of view. But let's call a spade a spade and not tip toe around it with bullshit pseudo-arguments like 'ease of deployability' and 'social sharing' and 'portability' and 'platform-agnosticity'.
  - 13y ago

ux-app 13y ago

That is very cool. I got quite bad rubber banding initially (with a reported 60fps), however after turning off v-sync in chrome://flags I got super smooth 120fps performance. Would be great if Chrome had this option off by default.

exDM69 13y ago
> Would be great if Chrome had this option off by default. Disabling Vsync causes page tearing artifacts (https://en.wikipedia.org/wiki/Page_tearing https://en.wikipedia.org/wiki/Page_tearing). It should always be enabled by default. Some new gpu drivers also have "adaptive vsync", where it's enabled by default but gets temporarily disabled when deadlines are not met.
- ux-app 13y ago
  isn't tearing preferable to input lag? As I mentioned, with v-sync on there is a very noticeable rubber-banding effect, with it off the result is (perceptually) far smoother. >It [vsync] should always be enabled by default Not sure about this. Surely the goal is to maximize perceived performance not 'correctness' (where correctness in this context is defined as each frame being fully drawn before the next one starts).
  - exDM69 13y ago
    > isn't tearing preferable to input lag? In a properly written app, vsync should not cause input lag despite gamer superstitions. But there are lots of not-properly written apps where this is a problem. WebGL / Chrome should solve the problem in some other way, not disabling vsync. Or using adaptive vsync if available as a workaround. The culprit here might be the ANGLE OpenGLES2-on-D3D9 wrapper that Chrome uses, which is notoriously slow on synchronous operations like vsync, glGetError or glFinish.
just2n 13y ago
That was just caused by me not processing input properly. I've set up a proper rendering loop here and now only render the most recent mouse position on each frame: http://jsfiddle.net/eymAS/84/ http://jsfiddle.net/eymAS/84/ It's better, but still limited to 60fps, and since I render to the state at 0s, the worst delay we can see is ~16.6ms + rendering time.

spyder 13y ago

For me the movement is smooth but it still lags behind the mouse with 10-20 px. The Firefox version of the demo has a little less lag but still looks disconnected from the mouse when moved.

cpleppert 13y ago

The problem is that the DOM is a hard upper limit on performance compared to what the performance of an unsafe language (asm.js) is. It is massively complex because it must perform every UI task in the browser and simply moving around DIVs doesn't give you a feel for its the performance in complex scenarios. If you think about how native applications perform and then imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction you get a sense of what the problem is. There is simply no way to get the DOM to do something it wasn't designed to do, which is to be a document display interface and not a general graphical user interface. You have to clobber together a lot of interactions to get the desired behavior and not only does this increase the overhead for both your program and the DOM you are going to hit cases where the DOM isn't optimized. This doesn't mean that the DOM is inherently slow. If you tried to offload the UI work onto javascript you wouldn't get the performance benefit of doing that on Asm.js or NACL. You really need unsafe code to solve this problem. Asm.js and NACL are only useful if you are going to do this; targeting the Canvas and WebGL gives you the ability to do that.

BrendanEich 13y ago
asm.js is not an "unsafe language". /be
vladmoz 13y ago
What you describe -- "imagine every one having to go through a DOM interface and every button and UI interaction being composed of DOM elements and re-styling these elements on every interaction" -- is exactly how Firefox is built. The desktop Firefox UI is all DOM elements (not HTML, but still the same underlying DOM code). Hovering over a toolbar button or a tab causes a CSS style rule for a :hover effect to be applied. Opening a new tab uses CSS animation for the transition. Moving tabs around manipulates the DOM and moves the tab elements (which are themselves composed of images, labels, etc.). And yet, the Firefox UI is plenty snappy -- yes, you can argue that there are slowdowns and issues that need to be fixed, but no more or less than in many "native" apps.