4 ms·

Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n). I think out of practicality it wasn't adopted. It would b

by mahyarm 10y ago

Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n). I think out of practicality it wasn't adopted. It would be better if both were available, but such is life. http://floriankugler.com/2013/04/22/auto-layout-performance-on-ios/ http://floriankugler.com/2013/04/22/auto-layout-performance-...

Animats 10y ago
It's used for screen layout in MacOS Lion and Grid Style Sheets.[1] There's also a subdomain that goes faster, and simple layouts should be in that subdomain. The idea is to get away from programmer-oriented layout input.
- ryanbrunner 10y ago
  Right, but neither Lion or Grid Style Sheets were available in the early 90's. It may have been possible to implement, sure, but we're talking early enough in the web's history that the performance of the styling engine was a legitimate concern.
  - shrugger2 10y ago
    Sure, but now we're past all that and people still come up with bullshit reasons that CSS SHOULDN'T be replaced when there is every reason to believe that we can do a better job now that we've suffered through 20 years of learning.
junke 10y ago
Some systems can be linear and solved in real-time. https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf https://constraints.cs.washington.edu/solvers/cassowary-toch...
jomamaxx 10y ago
"Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n)." Those are the upper bounded constraints, but not reality. Pragmatically, there's no reason 'constraint bounded' algs can't - in practice - approach procedural layouts. Second, is the fact that layout is becoming less and less of an issue re: performance, to the point that in a few years, the argument may be moot. Third, I'd argue that 'performance' is only one factor. But good point.
- mahyarm 10y ago
  I wish iOS autolayout wasn't n^2. You have to realize these algorithms have very small time budgets and you can start seeing stutters when you use them in things like UICollectionViews and UITableViews and other scrolling / gesture contexts. Performance is still a very real thing for these things. Devices you support will also last 5+ years and I don't think we will see the same power/performance ratio gains in mobile in the next 5 years like we have in the last 5 years. I bought an iPad Mini 4 recently and I see general stuttering in the OS programs alone and it's the most recent iPad Mini you can buy! You can have something pretty close to constraint based layouts in procedural layouts in something like "snap view 1 bottom to view 2 top", etc.

by mahyarm 10y ago

Animats 10y ago

It's used for screen layout in MacOS Lion and Grid Style Sheets.[1] There's also a subdomain that goes faster, and simple layouts should be in that subdomain. The idea is to get away from programmer-oriented layout input.

ryanbrunner 10y ago
Right, but neither Lion or Grid Style Sheets were available in the early 90's. It may have been possible to implement, sure, but we're talking early enough in the web's history that the performance of the styling engine was a legitimate concern.
- shrugger2 10y ago
  Sure, but now we're past all that and people still come up with bullshit reasons that CSS SHOULDN'T be replaced when there is every reason to believe that we can do a better job now that we've suffered through 20 years of learning.

junke 10y ago

Some systems can be linear and solved in real-time. https://constraints.cs.washington.edu/solvers/cassowary-tochi.pdf https://constraints.cs.washington.edu/solvers/cassowary-toch...

jomamaxx 10y ago

"Constraint layout systems are O(n^2) algorithms, while a procedural layout algo can be O(1) or O(n)." Those are the upper bounded constraints, but not reality. Pragmatically, there's no reason 'constraint bounded' algs can't - in practice - approach procedural layouts. Second, is the fact that layout is becoming less and less of an issue re: performance, to the point that in a few years, the argument may be moot. Third, I'd argue that 'performance' is only one factor. But good point.

mahyarm 10y ago
I wish iOS autolayout wasn't n^2. You have to realize these algorithms have very small time budgets and you can start seeing stutters when you use them in things like UICollectionViews and UITableViews and other scrolling / gesture contexts. Performance is still a very real thing for these things. Devices you support will also last 5+ years and I don't think we will see the same power/performance ratio gains in mobile in the next 5 years like we have in the last 5 years. I bought an iPad Mini 4 recently and I see general stuttering in the OS programs alone and it's the most recent iPad Mini you can buy! You can have something pretty close to constraint based layouts in procedural layouts in something like "snap view 1 bottom to view 2 top", etc.