Bug 50039 – [chromium] Disable antialiasing for compositor

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Kenneth Russell]

Chromium's compositor uses GraphicsContext3D for its rendering, and by default requests antialiasing via GraphicsContext3D::Attributes. Currently antialiasing is only implemented for off-screen contexts, not those which render directly to the HostWindow -- except on Mac OS X, which has offscreen context behavior in both cases. This causes a feature disparity between platforms and also negatively impacts performance on Mac because multisampling consumes fill rate. To achieve platform parity we need to explicitly disable antialiasing for the compositor.

[Kenneth Russell]

Created attachment 74791 [details]
Patch

[Vangelis Kokkevis]

Comment on attachment 74791 [details]
Patch

Looks good.

[Kenneth Russell]

Committed r72703: <http://trac.webkit.org/changeset/72703>

[Nico Weber]

This makes us look considerably worse than Safari.

[Kenneth Russell]

(In reply to comment #4)
> This makes us look considerably worse than Safari.

As indicated in the comment, more work is needed in order for us to successfully enable antialiasing for the compositor. We need the on-screen case to work on Windows and Linux, but more importantly, we need to measure and address the significant performance issues particular to our Mac OS X port.

[Nico Weber]

Other windows and linux browsers don't support compositing, so there's no direct comparison there. Do you have any data how much performance we get from this? On OS X, "pretty" usually beats "a bit faster".

[Kenneth Russell]

(In reply to comment #6)
> Other windows and linux browsers don't support compositing, so there's no direct comparison there. Do you have any data how much performance we get from this? On OS X, "pretty" usually beats "a bit faster".

With two copies of the aquarium demo open ( http://webglsamples.googlecode.com/hg/aquarium/aquarium.html ) on my MacBook Pro, with antialiasing on and http://codereview.chromium.org/5317007 landed we get 15 FPS per window. With antialiasing off we get 20 FPS per window. Firefox 4.0b7, which does all of its compositing in-process, gets 45 FPS per window. The performance impact is significant. However, we are still far behind even with antialiasing disabled.

I've filed http://crbug.com/64385 to track one necessary performance optimization on our side. Once that is landed we can re-measure and consider turning antialiasing back on for the compositor. I don't think we should do so before this.

We also need to figure out whether there is anything we can be doing differently or better with IOSurfaces. I have a feeling that their copying semantics are causing us to run into fill rate limitations more quickly than browsers that can do all of their compositing in a single process.

[Nico Weber]

Thanks for the data and the pointer to that bug. SGTM.