This bug kind of blocks 667551 - even if we add OOPIF support for pixel dumps, we cannot enable running pixel-dumps-dependent layout tests until there are no pixel differences.

Unlike in issue 740291, the differences in this bug are very small and (for me at least) are impossible to see with a naked eye.

Example #1 - there is a 1 pixel difference to the left of the lower case "e" in "Frame body":
- In cross-site-frame-actual.png this pixel is r=248, g=248, b=248
- In cross-site-frame-expected.png this pixel is r=247, g=247, b=247

Example #2 - there is a 1 pixel difference between the lower case "d" and "o" in "Lorem ipsum dolor":
- In cross-site-frame-actual.png this pixel is r=252, g=252, b=252
- In cross-site-frame-expected.png this pixel is r=251, g=251, b=251

The difference no longer repros after hardcoding antialiasing to false in:

- chrome/browser/renderer_preferences_util.cc: UpdateFromSystemSettings
- chrome/browser/ui/libgtkui/gtk_ui.cc: GetGtkFontRenderParams
- ui/gfx/font_render_params.cc: FontRenderParams::FontRenderParams
- ui/gfx/font_render_params_linux.cc: QueryFontconfig

I am not familiar with the design of OOPIF but could it be that the origin coordinate of the iframe is clamped differently when switching between OOPIF on and off? There might be a small difference in coordinate transformations or text rendering target coordinates between OOPIF and non OOPIF which causes these subpixel antialiasing differences. Perhaps another way of fixing this would be to make non-OOPIF iframes behave in the same way?

Am I right in understanding there are no pixel differences with the patch when not using the --site-per-process flag? Or do you get pixel differences with the patch in both modes?

Layout tests draw with these RendererSettings today: https://cs.chromium.org/chromium/src/content/test/layouttest_support.cc?rcl=5602e852d482212446cab44097f2907d64297217&l=351

Which may not match the browser process exactly (for whom they are defined in GpuProcessTransportFactory), and could result in small differences that would need to be rebaselined if they changed.

RE: #c8

Browser-side pixel dumps (i.e. https://codereview.chromium.org/2962073002) succeed (show *no* pixel differences: actual pixels == expected pixels) without --site-per-process and fail (show pixel differences: actual pixels != expected pixels) with --site-per-process.

Note that .../LayoutTests/http/tests/cross-site-frame-expected.html (from https://codereview.chromium.org/2962073002) replicates .../LayoutTests/http/tests/cross-site-frame.html, except that the subframe is same-site as the main frame.  Therefore, there are no baseline/expected pixels (there is only a reference html that should be rendered/composited in an equivalent way).

RE: #c9

FWIW, I think that the potential browser-vs-renderer difference is a red herring - in my 2 tests, I always capture the pixels in the browser process (except that one time running with and one time running without --site-per-process flag).

Thanks for pointing out RendererSettings::allow_antialiasing.  I've looked at the 4 places under //cc/output that inspect RendererSettings::allow_antialiasing and I see that cc/output/gl_renderer.cc uses a slightly different condition than the cc/output/software_renderer.cc:

    cc/output/gl_renderer.cc:

        bool allow_aa = settings_->allow_antialiasing &&
                        !quad->force_anti_aliasing_off && quad->IsEdge();

    cc/output/software_renderer.cc:

        // TODO(danakj): Until we can enable AA only on exterior edges of the
        // layer, disable AA if any interior edges are present. crbug.com/248175
        bool all_four_edges_are_exterior = quad->IsTopEdge() &&
                                           quad->IsLeftEdge() &&
                                           quad->IsBottomEdge() &&
                                           quad->IsRightEdge();
        if (settings_->allow_antialiasing &&
            (settings_->force_antialiasing || all_four_edges_are_exterior))
          current_paint_.setAntiAlias(true);

I vaguely remember that OOPIFs might be forced to always use software rendering (although it is quite possibly that I am misremembering).  But then - I still got the same pixel differences even after changing cc/output/software_renderer.cc to say |settings_->allow_antialiasing && quad->IsEdge()|.

Is there a particular test that fails? I don't see any listed here. Going
to close this bug since it doesn't seem actionable in the presence of other bugs
tracking OOPIF layout tests.