I've played around with https://codereview.chromium.org/2964563002 and I am sad to see that some tests that passed without threaded compositing are failing when threaded compositing is the new default.

One example is fast/events/pointerevents/mouse-pointer-capture.html, which crashes when processing input events (simulated by the test AFAICT).

Another example is differences in expected pixel output.  In some cases like animations/skew-notsequential-compositor.html and css3/filters/filter-repaint-child-layers.html and fast/table/border-radius-with-image.html the differences are very subtle and almost unnoticable without using image comparison tools.  In other cases, the differences are quite big - for example in fast/forms/color/color-suggestion-picker-appearance.html the snapshot appeared surprisingly big.

FWIW, I am attaching a list of layout tests that might fail after the switch (and that might be useful for feeding into run-webkit-tests's --test-list parameter).  I haven't closely looked at all the test failures - some failures might highlight actual differences between threaded and non-threaded behavior, while some failures might be related to insufficiently careful manipulation of test exceptions done in my CL.

Deleted: compositor-tests2.txt 7.7 KB

compositor-tests2.txt 7.7 KB View Download

Sorry, but I feel pretty strongly in the opposite direction.  A number of us over the years have tried to make layout tests threaded and ran into all sorts of flakiness issues.  Having Blink being able to control the scheduling of frames explicitly makes layout tests a lot more reliable.

In general, we have *never* seen a bug that has been caught because of some difference between single threaded and threaded differences in the compositor.  It's an abstraction that doesn't make any sense to test at the level of layout tests, in my opinion.  Blink currently has some behavior where it behaves differently wrt animations when it's in threaded mode vs not (in that it doesn't create compositor thread animations), but I think this is really a bug.  There's no reason that the single threaded compositor couldn't support these, and having a mode difference makes code more fragile.

I would rather see all layout tests run in single threaded compositing mode if I had my druthers.


Re: checker imaging.  It sounds like RenderWidgetCompositor needs to turn off checker imaging in the settings when it's in single threaded mode and it isn't now.

Also, I'm not sure what you mean by "this is how chrome works".  ui uses single threaded compositing, so it's not as if this is an unsupported configuration.

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ZW2wDejtRdo/bNIfUiCNDwAJ

Thanks for the historical information - this is very useful.

My main motivation for opening this bug was a failed attempt for supporting pixel dumps that span OOPIFs - if this can be solved, than I don't have a strong opinion for the threaded/non-threaded compositing mode that layout tests run in.  I would appreciate if you could take a look and leave your comments/suggestions in  issue 667551 .

RE: Also, I'm not sure what you mean by "this is how chrome works".

I meant that when I launch chrome with --disable-threaded-compositing, then I very quickly run into a crash in the renderer process.  I assumed that this means that on user machines the renderer runs in threaded compositing mode.  I further assumed that we want to test what ends up being used by the users, but I admit that I know almost nothing about compositing and I have to trust you when you say that the difference is not meaningful.

>  I further assumed that we want to test what ends up being used by the users

We do, but layout tests are not for testing the compositor, they use a compositor to output what blink did and we're testing blink in them. We have unit tests for the compositor that test threaded mode.

1. This doesn't really block  issue 667551 
2. The consensus seems to be that we want to continue running layout tests without a separate compositor thread (e.g. for deterministic test results).