[webkit-dev] Many crashs of regresion tests in 64-bit Windows
64-bit Window 7. run-webkit-tests reported that many tests crashed, in addition to many other failures due to the metric difference. Command line: Tools/Scripts/run-webkit-tests compositing/iframes Tests that caused DumpRenderTree tool to crash: compositing/iframes/connect-compositing-iframe3.html stderr of connect-compositing-iframe3.html: ASSERTION FAILED: !isAcceleratedCompositing() ..\WebView.cpp(1083) : WebView::paintIntoBackingStore The result and crash log have been attached in this message. layout-test-results.tar.gz Description: GNU Zip compressed data ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows
On Apr 5, 2011, at 1:02 PM, Pere Martir wrote: 64-bit Window 7. run-webkit-tests reported that many tests crashed, in addition to many other failures due to the metric difference. Command line: Tools/Scripts/run-webkit-tests compositing/iframes Tests that caused DumpRenderTree tool to crash: compositing/iframes/connect-compositing-iframe3.html stderr of connect-compositing-iframe3.html: ASSERTION FAILED: !isAcceleratedCompositing() ..\WebView.cpp(1083) : WebView::paintIntoBackingStore The result and crash log have been attached in this message. layout-test-results.tar.gz The best way to report a bug like this is to file a new bug at http://webkit.org/new-bug. In this case, this is a known issue (http://webkit.org/b/52913), so you don't need to do anything. There isn't a workaround at this time, other than to skip those tests or use a Release build. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows
On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben aro...@apple.com wrote: The best way to report a bug like this is to file a new bug at http://webkit.org/new-bug. In this case, this is a known issue (http://webkit.org/b/52913), so you don't need to do anything. There isn't a workaround at this time, other than to skip those tests or use a Release build. Thanks. I didn't know that this is a bugI thought that it might be due to the configuration of my Windows 7. Should I always report this kind of issue directly to Bugzilla instead of posting them here first ? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows
On Apr 5, 2011, at 1:17 PM, Pere Martir wrote: On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben aro...@apple.com wrote: The best way to report a bug like this is to file a new bug at http://webkit.org/new-bug. In this case, this is a known issue (http://webkit.org/b/52913), so you don't need to do anything. There isn't a workaround at this time, other than to skip those tests or use a Release build. Thanks. I didn't know that this is a bugI thought that it might be due to the configuration of my Windows 7. Should I always report this kind of issue directly to Bugzilla instead of posting them here first ? Yes, please. Bugzilla is our best tool for keeping track of bugs, even if they turn out to eventually be specific to some misconfiguration on the developer's system. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] embedding pixel result checksum in the png
I propose that we move away from checking in separate .checksum files for pixel tests and instead embed the checksum in the .png file as a comment. There are two main benefits of doing this: 1) Less files in the tree - faster git/svn operations. Currently, in LayoutTests, 32,650 out of 141,170 files are checksum files (23% of the files). 2) Less likely to accidentally check in a .checksum without a .png or a .png without a .checksum. We're currently trying this out in the Chromium port, but I would like to add this to the other ports as well. To make embedded checksums easier to use, I've added a script Tools/Scripts/read-checksum-from-png that will read the checksum from a png file passed in on the command line. I've also updated the flakiness dashboard and plan on updating PrettyPrint.rb so you can see the checksums in a diff. If there are other tools or workflows that might be interrupted by this change, please let me know and I will update those tools as well. If there are no objections to this, my plan is as follows: a) Update DRT to write the checksum to png files. b) Update run-webkit-tests to read the checksum from png files if the .checksum file is absent. c) Update webkit-patch rebaseline to not copy over the .checksum file. d) Update run-webkit-tests --reset-results and --new-baseline to not write .checksum files. e) Start converting old results to the new format (i.e., put the checksum in the png and delete the .checksum file). Thoughts or suggestions for improvement? tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] embedding pixel result checksum in the png
Sounds like a great idea, as long as reading the checksum is still fast. I couldn’t tell when you mentioned run-webkit-tests in your steps what your specific plans are for old-run-webkit-tests and new-run-webkit-tests. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] embedding pixel result checksum in the png
This is awesome! On Wed, Apr 6, 2011 at 5:11 AM, Tony Chang t...@chromium.org wrote: c) Update webkit-patch rebaseline to not copy over the .checksum file. I don't think you need to do this. webkit-patch rebaseline is very basic right now. I think it only does the right thing for dumpAsText tests. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] embedding pixel result checksum in the png
Yes, reading the checksum is the same speed as before. We write the png comment at the beginning of the file and only scan the first 2k of the file for the checksum. I also tried converting about 200 tests to use embedded checksums and found no speed difference. I've already updated new-run-webkit-tests, but plan on updating old-run-webkit-tests as well since it's a small amount of code (only about 20 lines of python, I imagine the amount of perl will be similar). On Tue, Apr 5, 2011 at 3:55 PM, Darin Adler da...@apple.com wrote: Sounds like a great idea, as long as reading the checksum is still fast. I couldn’t tell when you mentioned run-webkit-tests in your steps what your specific plans are for old-run-webkit-tests and new-run-webkit-tests. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] embedding pixel result checksum in the png
Hi, The idea is awesome. ;) Getting rid of ~32k checksum files would speedup svn operations. I support you're works, please cc me to the bug report. br, Ossy Tony Chang írta: Yes, reading the checksum is the same speed as before. We write the png comment at the beginning of the file and only scan the first 2k of the file for the checksum. I also tried converting about 200 tests to use embedded checksums and found no speed difference. I've already updated new-run-webkit-tests, but plan on updating old-run-webkit-tests as well since it's a small amount of code (only about 20 lines of python, I imagine the amount of perl will be similar). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas backing resolution
Did this move anywhere? http://www.w3.org/Bugs/Public/show_bug.cgi?id=11328 https://bugs.webkit.org/show_bug.cgi?id=51190 http://code.google.com/p/chromium/issues/detail?id=66656 Firefox is a nasty CSS hack, but it does work, and that's something to be happy about. Microsoft makes it easy; Firefox developers have said they do not want it to be easy. http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx https://bugzilla.mozilla.org/show_bug.cgi?id=486200 From Robert O, reflecting Mozilla's policy: I don't want Web authors to have easy access to information about screen pixels. They'll try to defeat our zooming or size things to screen pixels, which we don't want. WebKit and MS already diverge from Firefox in handling of window.innerWidth/innerHeight and window.screen properties. That's not news. I'd really like to see a resolution to this issue. The hacks I'm using just aren't stable in the long term. I'd prefer the property were just exposed to the DOM via window.screen, as MS has done it, but I'm ok doing CSS media queries. It's just that media queries require something of a brute-force of case statements; I have about ~12 media queries to handle Firefox, all just repeating min media query, trying to narrow down the resolution. Long-story-short, can we please expose some of the CSS pixel scaling, either through window.devicePixelRatio, through CSS media queries on device-pixel-ratio, or through the window.screen object, in a way similar to how MS has done it Anything will work.. I just need one. -Charles On 3/4/2011 12:02 PM, Kenneth Rohde Christiansen wrote: Hi Simon, I guess you could use the media query listener defined in http://dev.w3.org/csswg/cssom-view/#the-mediaquerylist-interface We support that on trunk now. This of course means that we will need to reevaluate the CSS when a pinch zoom ends, which we might be doing already given media queries such as @media all and (min-width: 200px). Cheers Kenneth On Fri, Mar 4, 2011 at 8:47 PM, Simon Frasersimon.fra...@apple.com wrote: On Mar 4, 2011, at 11:24 AM, Kenneth Rohde Christiansen wrote: Hey Oliver! If you are saying that device-pixel-ratio should include the user scaling, then I can push that for Qt, but I would really like seeing it supported by iOS as well for compatibility reasons. If you create a bug for that, please cc me. There's a problem with that, which is that the author can assume (possibly erroneously) that device-pixel-ratio doesn't change for the life of the page. However, the zoom level can change often, and there's no notification that the author can register for that will tell them when the zoom level changes, and thus when they'll need to redraw their canvas contents. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
