4 ms·

"Allows only features that are fast/can be gpu accelerated" is a nice idea in theory, but in practice it's wrong. The web started out as a platform where no fea

"Allows only features that are fast/can be gpu accelerated" is a nice idea in theory, but in practice it's wrong. The web started out as a platform where no features were accelerated, and browser vendors started incrementally adding faster software implementations of features, and then eventually GPU-accelerated implementations. More obscure/uncommonly used features tend not to get an optimized implementation, because carefully tuning every single web platform feature is extremely expensive to do. So if AMP forbids things that aren't fast Right Now, you're freezing the state of the platform forever until vendors get around to improving features nobody uses... and then you have to wait until every vendor ships the optimized implementation before anyone can use it in AMP. The fact is that there are many barriers between web apps and native-level performance. AMP's focus on delivering good performance on mobile is to be applauded, but you don't do it by trapping software in the past. (Context: Previous member of Firefox and Chrome teams)

pcwalton 10y ago
> So if AMP forbids things that aren't fast Right Now, you're freezing the state of the platform forever until vendors get around to improving features nobody uses... and then you have to wait until every vendor ships the optimized implementation before anyone can use it in AMP. Agreed that AMP is the wrong approach. But I think it's not that difficult in terms of programmer-months to fix the rasterization problems. You just need the right design as opposed to '90s style imperative APIs.
kartickv 10y ago
When a new feature is being developed, whether it can be GPU-accelerated on day 1 should be a factor in the decision. If it can't, or it's tricky, perhaps we should think twice before even developing the feature. Rather than it being an afterthought, as it seems today. Of course, all this is in the context of features that make sense to GPU-accelerate, like CSS filters.

pcwalton 10y ago

> So if AMP forbids things that aren't fast Right Now, you're freezing the state of the platform forever until vendors get around to improving features nobody uses... and then you have to wait until every vendor ships the optimized implementation before anyone can use it in AMP. Agreed that AMP is the wrong approach. But I think it's not that difficult in terms of programmer-months to fix the rasterization problems. You just need the right design as opposed to '90s style imperative APIs.

kartickv 10y ago

When a new feature is being developed, whether it can be GPU-accelerated on day 1 should be a factor in the decision. If it can't, or it's tricky, perhaps we should think twice before even developing the feature. Rather than it being an afterthought, as it seems today. Of course, all this is in the context of features that make sense to GPU-accelerate, like CSS filters.