3 ms·

At a clock rate of 2 GHz, at least 64 million cycles will elapse during multiple frames (> 32 milliseconds) of layout. What makes flexbox layout so inherently

by panic 10y ago

At a clock rate of 2 GHz, at least 64 million cycles will elapse during multiple frames (> 32 milliseconds) of layout. What makes flexbox layout so inherently complicated that computing it takes such a huge number of operations? Maybe we should come up with ways of specifying layout that take fewer operations to compute.

eddyb 10y ago
But how many times can you access the DRAM in that time? One thing you have to keep in mind is that the more dynamic the scene graph, and the larger its memory footprint, the more frequent you'll miss the cache while traversing it. It's possible to manually write optimized flex-box-like layout code, where the overall structure, if not exact position, is mostly static. For example, if you always have one resizable panel to the side of two viewports, of equal width (as is the case in the editor I use atm), you can easily do `viewport_width = (total_width - panel_width) / 2` and be done. Those operations, if done with integers, should be faster than a read from cache, or if done with floating-point numbers, (much) faster than going to DRAM in the even of a cache miss. However, doing all of that by hand would be a pain, and it's hopeless in the face of user customization. SIMD is another resource that's completely unusable in the face of truly dynamic data, and a time sink to do manually. What we're missing is automation of mostly-static UIs, generating specialized code and optimizing it into computations that run under a microsecond. For HTML, the hope would be JITs, but highly dynamic DOMs are still all over the place, so you're not going to have as many gains as a dedicated UI system, and it wouldn't be free for the user.
- panic 10y ago
  Yes, exactly! It seems like immediate-mode GUIs could actually lay out faster than retained-mode: you don't have a scene graph, and the layout code is just normal code that can be optimized by the compiler.
  - pcwalton 10y ago
    Layout code is always "normal code that can be optimized by the compiler". Why wouldn't it be? I think you're referring to applying optimizations to static UI with constant data structures, but that can be done with retained mode too, and I doubt it actually is going to help.
pcwalton 10y ago
When you consider that layout typically depends on fonts, which are hideously complicated, it's a lot worse than that. Text line breaking involves a lot of allocation, etc. Also, layout is typically memory-bound. The arithmetic intensity is sadly fairly low. I do agree with you, though. Sadly very few Web developers and designers care about performance of layout; all everyone seems to want is new features without any regard for performance...

by panic 10y ago

eddyb 10y ago

But how many times can you access the DRAM in that time? One thing you have to keep in mind is that the more dynamic the scene graph, and the larger its memory footprint, the more frequent you'll miss the cache while traversing it. It's possible to manually write optimized flex-box-like layout code, where the overall structure, if not exact position, is mostly static. For example, if you always have one resizable panel to the side of two viewports, of equal width (as is the case in the editor I use atm), you can easily do `viewport_width = (total_width - panel_width) / 2` and be done. Those operations, if done with integers, should be faster than a read from cache, or if done with floating-point numbers, (much) faster than going to DRAM in the even of a cache miss. However, doing all of that by hand would be a pain, and it's hopeless in the face of user customization. SIMD is another resource that's completely unusable in the face of truly dynamic data, and a time sink to do manually. What we're missing is automation of mostly-static UIs, generating specialized code and optimizing it into computations that run under a microsecond. For HTML, the hope would be JITs, but highly dynamic DOMs are still all over the place, so you're not going to have as many gains as a dedicated UI system, and it wouldn't be free for the user.

panic 10y ago
Yes, exactly! It seems like immediate-mode GUIs could actually lay out faster than retained-mode: you don't have a scene graph, and the layout code is just normal code that can be optimized by the compiler.
- pcwalton 10y ago
  Layout code is always "normal code that can be optimized by the compiler". Why wouldn't it be? I think you're referring to applying optimizations to static UI with constant data structures, but that can be done with retained mode too, and I doubt it actually is going to help.

pcwalton 10y ago

When you consider that layout typically depends on fonts, which are hideously complicated, it's a lot worse than that. Text line breaking involves a lot of allocation, etc. Also, layout is typically memory-bound. The arithmetic intensity is sadly fairly low. I do agree with you, though. Sadly very few Web developers and designers care about performance of layout; all everyone seems to want is new features without any regard for performance...