[landl0rd]

Ceteris paribus your performance is always going to be substantially worse even with tons of fancy tricks. Those also get much harder to implement when you're building a complete UI toolkit that has to support a ton of stuff rather than just writing first-party apps/OS components.

[gmueckl]

I think that the batching that I have in mind would work especially well with complex layouts. The thing to realize is that even if you have tons of elements on a screen, their visual components aren't actually stacked deeply in most cases and the type and order of applied effects is quite similar for large groups of elements. This allows for pretty effective per-level batching in hierarchies, even if elements don't have the same parents.

[chrisweekly]

"ceteris paribus" - "all else equal"

[landl0rd]

Right. My point is the response to this is "well if we optimize it more we'll improve performance", but oftentimes if you optimized the existing code you would also improve performance. Your end state is still worse.

[gmueckl]

Is it really worse if the GPU spends maybe 0.5ms more per frame on these effects? I'd be surprised if a good implementation adds much more to the per frame rendering time.

[landl0rd]

The consideration for mobile devices (laptops, tablets, and phones make up the bulk of apple's hardware sales) is more power consumption.

[gmueckl]

But even then it doesn't matter in practice. I dare you to measure the battery life impact of this change.

[butlike]

Thanks. Wasn't familiar with that latin