Bug 113096 – [chromium] make layout tests pass on retina displays

• Component: Tools / Tests
• Status: RESOLVED WONTFIX

[Dirk Pranke]

The apple mac port just landed a change to their DRT code to make the layout tests pass when running on a retina display (Bug 93673). Hopefully we can do something similar?

[Nico Weber]

See bug 93673.

We should do that (but it requires using private apis, boo :-/).

But just ticking the "Open in Low Resolution" box in finder->get info for DRT / Content Shell makes things work for me too, so it's maybe not uberly high priority?

[Dirk Pranke]

(In reply to comment #1)
> See bug 93673.
> 
> We should do that (but it requires using private apis, boo :-/).
> 
> But just ticking the "Open in Low Resolution" box in finder->get info for DRT / Content Shell makes things work for me too, so it's maybe not uberly high priority?

Interesting. I didn't know about that option. Does that persist across rebuilds, or can we programmatically tick set that settings somehow as part of the build?

[Nico Weber]

(In reply to comment #2)
> (In reply to comment #1)
> > See bug 93673.
> > 
> > We should do that (but it requires using private apis, boo :-/).
> > 
> > But just ticking the "Open in Low Resolution" box in finder->get info for DRT / Content Shell makes things work for me too, so it's maybe not uberly high priority?
> 
> Interesting. I didn't know about that option. Does that persist across rebuilds

Yes.

>, or can we programmatically tick set that settings somehow as part of the build?

From what I can tell, this is stored in the LSHighResolutionModeIsMagnified field (look through the output of `defaults read`, and look for that and org.chromium.ContentShell), but that seems to be Not Documented At All on the interwebs. So "not easily".

[Elliott Sprehn]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > See bug 93673.
> > > 
> > > We should do that (but it requires using private apis, boo :-/).
> > > 
> > > But just ticking the "Open in Low Resolution" box in finder->get info for DRT / Content Shell makes things work for me too, so it's maybe not uberly high priority?
> > 
> > Interesting. I didn't know about that option. Does that persist across rebuilds
> 
> Yes.
> 
> >, or can we programmatically tick set that settings somehow as part of the build?
> 
> From what I can tell, this is stored in the LSHighResolutionModeIsMagnified field (look through the output of `defaults read`, and look for that and org.chromium.ContentShell), but that seems to be Not Documented At All on the interwebs. So "not easily".

I just checked and my DRT already has this box checked (actually it's greyed out and checked so I can't even uncheck it). I still fail all the pixel tests because of text differences though.

[Elliott Sprehn]

(In reply to comment #4)
> ...
> 
> I just checked and my DRT already has this box checked (actually it's greyed out and checked so I can't even uncheck it). I still fail all the pixel tests because of text differences though.

My DumpRenderTree.app is missing the Info.plist file entirely too. How did you check this box Nico?

[Nico Weber]

(bleh, this comment didn't make it through thanks to a collision)

> I just checked and my DRT already has this box checked (actually it's greyed out and checked so I can't even uncheck it). I still fail all the pixel tests because of text differences though.

Ah, that's likely because it doesn't have an Info.plist file somehow (?).

I'm working on the new approach of running layout tests under Content Shell, and most tests pass for me (the ones that don't is because Content Shell DRT isn't done yet).

I ran a few tests with DRT, and they passed for me. Can you share a test that doesn't pass for you?

[Elliott Sprehn]

(In reply to comment #6)
> (bleh, this comment didn't make it through thanks to a collision)
> 
> > I just checked and my DRT already has this box checked (actually it's greyed out and checked so I can't even uncheck it). I still fail all the pixel tests because of text differences though.
> 
> Ah, that's likely because it doesn't have an Info.plist file somehow (?).
> 
> I'm working on the new approach of running layout tests under Content Shell, and most tests pass for me (the ones that don't is because Content Shell DRT isn't done yet).
> 
> I ran a few tests with DRT, and they passed for me. Can you share a test that doesn't pass for you?

fast/css-generated-content/001.html , it's actually all pixel tests though.

[Nico Weber]

> fast/css-generated-content/001.html , it's actually all pixel tests though.

Passes for me:

Nicos-MacBook-Pro:src thakis$   webkit/tools/layout_tests/run_webkit_tests.sh   fast/css-generated-content/001.html
Using port 'chromium-mac-mountainlion'
Test configuration: <mountainlion, x86, release>
Placing test results in /Users/thakis/src/chrome/src/webkit/Release/layout-test-results
Baseline search path: chromium-mac -> chromium -> generic
Using Release build
Pixel tests enabled
Regular timeout: 6000, slow test timeout: 30000
Command line: /Users/thakis/src/chrome/src/out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree -

Found 1 test; running 1, skipping 0.
    wdiff is not installed; please install from MacPorts or elsewhere

Running 1 DumpRenderTree.       

The test ran as expected.                


Do I do something wrong? Do I need to pass more flags? (This is with a webkit-in-chromium build)

[Dirk Pranke]

those are all the flags you should need to run. (I don't have a retina, so I can't help here).

[Elliott Sprehn]

(In reply to comment #8)
> > fast/css-generated-content/001.html , it's actually all pixel tests though.
> 
> Passes for me:
> 
>  ...
> Do I do something wrong? Do I need to pass more flags? (This is with a webkit-in-chromium build)

Do you have an Info.plist in there? I've got a chromium checkout where I deleted the third_party/WebKit dir and replaced it with a webkit checkout. If I add an Info.plist to my DumpRenderTree.app/Contents that contains:

<dict>
    <key>CFBundleDisplayName</key>
    <string>DumpRenderTree</string>
    <key>CFBundleExecutable</key>
    <string>DumpRenderTree</string>
    <key>CFBundleIdentifier</key>
    <string>org.chromium.DumpRenderTree</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>DumpRenderTree</string>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>NSSupportsAutomaticGraphicsSwitching</key>
    <true/>
    <key>NSHighResolutionCapable</key>
    <string>True</string>
</dict>

and then copy and pasting DumpRenderTree.app so the plist is reloaded enables the checkbox. Then I don't even need to check the checkbox (it's actually unchecked, but enabled now) and I can run and pass the tests.

[Elliott Sprehn]

Also I run the tests with:

./Tools/Scripts/run-webkit-tests --debug --chromium --no-retry-failures [test names]

I don't know what that script Nico is using does.

[Nico Weber]

(In reply to comment #10)
> (In reply to comment #8)
> > > fast/css-generated-content/001.html , it's actually all pixel tests though.
> > 
> > Passes for me:
> > 
> >  ...
> > Do I do something wrong? Do I need to pass more flags? (This is with a webkit-in-chromium build)
> 
> Do you have an Info.plist in there?

Nope:

Nicos-MacBook-Pro:src thakis$ ls -R out/Release/DumpRenderTree.app/
Contents

out/Release/DumpRenderTree.app//Contents:
MacOS		Resources

out/Release/DumpRenderTree.app//Contents/MacOS:
DumpRenderTree		DumpRenderTree.log	osmesa.so

out/Release/DumpRenderTree.app//Contents/Resources:
AHEM____.TTF			WebKitWeightWatcher100.ttf	WebKitWeightWatcher300.ttf	WebKitWeightWatcher500.ttf	WebKitWeightWatcher700.ttf	WebKitWeightWatcher900.ttf	textAreaResizeCorner.png
DumpRenderTree.pak		WebKitWeightWatcher200.ttf	WebKitWeightWatcher400.ttf	WebKitWeightWatcher600.ttf	WebKitWeightWatcher800.ttf	missingImage.png


Just a regular ninja build.

Can you try running tests using the script I'm using above? (Also, I'm doing a release build as those link faster)

[Dirk Pranke]

In reply to comment #11)
> Also I run the tests with:
> 
> ./Tools/Scripts/run-webkit-tests --debug --chromium --no-retry-failures [test names]
> 
> I don't know what that script Nico is using does.

That script is just a wrapper that adds --chromium to whatever other command line args you have.

[Dirk Pranke]

Elliott, do you have AppleFontSmoothing set somewhere in your defaults, maybe?

[Elliott Sprehn]

(In reply to comment #14)
> Elliott, do you have AppleFontSmoothing set somewhere in your defaults, maybe?

Which defaults would those be? I do have the display prefs set to one step up from Best (retina) for more screen space, and I have the "Use font smoothing when available" checkbox checked in the General prefs, but I think that's the default?

[Dirk Pranke]

(In reply to comment #15)
> (In reply to comment #14)
> > Elliott, do you have AppleFontSmoothing set somewhere in your defaults, maybe?
> 
> Which defaults would those be? I do have the display prefs set to one step up from Best (retina) for more screen space, and I have the "Use font smoothing when available" checkbox checked in the General prefs, but I think that's the default?

Those are the global defaults. In a Terminal window, run

% defaults read DumpRenderTree AppleFontSmoothing

(I think, writing this from memory)

that key should either be not set at all, or set to 2. If it's something else, all the text will render differently and you'll get image failures. (This has happened to me a couple times to no end of head scratching).

[Elliott Sprehn]

(In reply to comment #16)
> ...
> 
> that key should either be not set at all, or set to 2. If it's something else, all the text will render differently and you'll get image failures. (This has happened to me a couple times to no end of head scratching).

Interesting, that prints 0 for me. What does it print if it's not set at all?

[Dirk Pranke]

(In reply to comment #17)
> (In reply to comment #16)
> > ...
> > 
> > that key should either be not set at all, or set to 2. If it's something else, all the text will render differently and you'll get image failures. (This has happened to me a couple times to no end of head scratching).
> 
> Interesting, that prints 0 for me. What does it print if it's not set at all?

It'll tell you it's not set. 0 is bad (that turns off smoothing, and most of our baselines expect it to be on). Set it to 2 w/ 

% defaults write DumpRenderTree AppleFontSmoothing -int 2

and try it again?.

[Nico Weber]

(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > ...
> > > 
> > > that key should either be not set at all, or set to 2. If it's something else, all the text will render differently and you'll get image failures. (This has happened to me a couple times to no end of head scratching).
> > 
> > Interesting, that prints 0 for me. What does it print if it's not set at all?
> 
> It'll tell you it's not set. 0 is bad (that turns off smoothing, and most of our baselines expect it to be on). Set it to 2 w/ 
> 
> % defaults write DumpRenderTree AppleFontSmoothing -int 2
> 
> and try it again?.

(Or, better yet, delete the custom pref: `defaults delete DumpRenderTree AppleFontSmoothing` I think.)