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?
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?
(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?
(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".
(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.
(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?
(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?
(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.
> 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)
those are all the flags you should need to run. (I don't have a retina, so I can't help here).
(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.
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.
(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)
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.
Elliott, do you have AppleFontSmoothing set somewhere in your defaults, maybe?
(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?
(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).
(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?
(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?.
(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.)