Hacker News Reader

Comment by pcwalton | Hacker News Reader

AMP doesn't "allow only CSS filters that can be GPU-accelerated". It allows only CSS properties that Blink (and other current engines) can GPU-accelerate via layers. There is no need for this restriction in general, and I think a better approach for the long run is to adopt rasterization strategies that don't have such unnecessary performance cliffs.

(Disclaimer: I work on one of these libraries.)

View on HN

Would be interested in taking a look at your project if you'd offer a link. :-)

The Amp guys make the claim in one of their videos[1] that the GPU can do nothing if a page-layout event is triggered. Amp is geared to minimizing the number of times this has to happen, by demanding that elements are size-bounded for example; the same reason for the CSS GPU-acceleration limits.

Hopefully new render engines will address this, but having them out in the wild is a ways off even if they were ready today. Amp seems like a pretty reasonable stop gap. Although I find their demo site[2] not a perfect experience with all of my normal Firefox plugins. Another comment in that video mentioned above is that Amp sites should be faster without an ad blocker.

[1] https://youtu.be/hVRkG1CQScA

[2] https://www.ampproject.org

> The Amp guys make the claim in one of their videos[1] that the GPU can do nothing if a page-layout event is triggered.

That's a Blink restriction, not an inherent one. It's also an onerous restriction. Having these footguns is a bad way to treat Web developers.

> Would be interested in taking a look at your project if you'd offer a link. :-)

WebRender [1], part of Servo.

[1]: https://github.com/servo/webrender

The AMP team 100% agrees with you. But the project goal is to be fast in current generation browsers. As soon as the current generation can perform well with more relaxed rules, the rules in AMP can be changed accordingly.

Reply on news.ycombinator.com