89715 2012-06-21 17:13:54 -0700 devicePixelRatio media query layout tests fail when deviceScaleFactor is greater than 1 2012-08-10 12:40:25 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Unspecified Unspecified NEW InRadar, LayoutTestFailure P2 Normal --- 1 bdakin webkit-unassigned bdakin dpranke webkit-bug-importer oldest_to_newest 655048 0 bdakin 2012-06-21 17:13:54 -0700 These two layout tests fail when you run them on a Retina Macbook Pro or any Mac running in HiDPI mode: fast/media/mq-max-pixel-ratio.html fast/media/mq-pixel-ratio.html They behave correctly, but the results that are checked are the results for a 1x display. We could easily change these tests to be display-agnostic, but since there are other differences in HiDPI, it would also be nice to have a new directory like the platform directory for test results that are specific to different deviceScaleFactors. 655049 1 webkit-bug-importer 2012-06-21 17:14:48 -0700 <rdar://problem/11723762> 692755 2 dpranke 2012-08-10 11:45:55 -0700 Could these tests could be rewritten to be text-only and use js/dom to query the color being rendered, or is it critical that we actually verify the pixels themselves? 692766 3 bdakin 2012-08-10 11:51:37 -0700 (In reply to comment #2) > Could these tests could be rewritten to be text-only and use js/dom to query the color being rendered, or is it critical that we actually verify the pixels themselves? The pixels are not critical in this case, but I think that they only way to truly convert these to text-only tests would be to extend DRT/WTR to be able report back the current device scale factor. The JS/DOM query for devicePixelRatio should not be used because these tests are essentially testing whether or not that very mechanism is accurate, so it needs to be compared against an alternate source of the information. So it would be possibly to avoid separate text expectations in this case if we extended the test harness. But I think it would be simpler to have a platform directory for results since there are still other tests that cannot be translated into text-only tests. For example, all of the canvas tests: https://bugs.webkit.org/show_bug.cgi?id=89709 692771 4 dpranke 2012-08-10 11:56:03 -0700 (In reply to comment #3) > (In reply to comment #2) > > Could these tests could be rewritten to be text-only and use js/dom to query the color being rendered, or is it critical that we actually verify the pixels themselves? > > The pixels are not critical in this case, but I think that they only way to truly convert these to text-only tests would be to extend DRT/WTR to be able report back the current device scale factor. The JS/DOM query for devicePixelRatio should not be used because these tests are essentially testing whether or not that very mechanism is accurate, so it needs to be compared against an alternate source of the information. > Fair enough. > So it would be possibly to avoid separate text expectations in this case if we extended the test harness. But I think it would be simpler to have a platform directory for results since there are still other tests that cannot be translated into text-only tests. For example, all of the canvas tests: https://bugs.webkit.org/show_bug.cgi?id=89709 Sure, I have no problem with a platform dir for tests that actually need images (or different text results or whatever), I was just looking for ways to convert some pixel tests to text-only. I was also wondering if these could be reftests, but I'm not seeing an obvious way to do that, either. 692816 5 bdakin 2012-08-10 12:40:25 -0700 (In reply to comment #4) > Sure, I have no problem with a platform dir for tests that actually need images (or different text results or whatever), I was just looking for ways to convert some pixel tests to text-only. > > I was also wondering if these could be reftests, but I'm not seeing an obvious way to do that, either. Okay, cool! Yeah, it's true that it's a good goal to have fewer pixel tests anyway. We should definitely consider extending DRT/WRT for this purpose.