Re: [webkit-dev] WebSocket Server failing to start on Tiger Bot?
Looks like it fixed itself: http://build.webkit.org/results/Tiger%20Intel%20Release/r53114%20(7655)/results.html Now just needs new results after http://trac.webkit.org/changeset/53114 Sorry for the noise. -eric On Mon, Jan 11, 2010 at 8:42 PM, Eric Seidel wrote: > WebSocket Server failing to start on Tiger Bot? > > http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/7654/steps/layout-test/logs/stdio > > This started happening after the master-restart this afternoon. I > don't see any related changes around that time. > > Can someone whack the bot over the head? > > -eric > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebSocket Server failing to start on Tiger Bot?
WebSocket Server failing to start on Tiger Bot? http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/7654/steps/layout-test/logs/stdio This started happening after the master-restart this afternoon. I don't see any related changes around that time. Can someone whack the bot over the head? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Scrolling / redraw issue on WinCE platform
Hi Jason, On Mon, Jan 11, 2010 at 10:53 AM, Jason Rukman wrote: > Actually SetGraphicsMode is not available at all on WinCE so I've > disabled this in a number of places; however, I've also tested that none > of these disabled locations are being hit at this point. I found them mainly by noticing problems like you describe. For example, I had a terrible problem where scrolling the page up/down resulted in what appeared to be partial repaints of the screen. For a long time I thought that the contents were being drawn 'invisibly' because I could highlight regions of the page and the contents would suddenly appear. It turned out that the World Transform was not being kept in sync with various translation changes in the Cairo drawing context, so the backing store did not match what was meant to appear on screen resulting in the bizarre behavior I observed. It might be that parts of the system are translating the XFORM, expecting future draw events to be making use of this XFORM change. If the XFORM is never updated (since you don't have SetGraphicsMode), the widget continues to be drawn in the same spot. I'd be on the lookout for places where TransformationMatrix is used, as this is the 'generic' structure used throughout the core. Maybe one or two of these are tasked with your scroll translation, and are not getting used. In this case, you'll have to adjust the rect used for drawing manually. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Scrolling / redraw issue on WinCE platform
Hi Brent, Actually SetGraphicsMode is not available at all on WinCE so I've disabled this in a number of places; however, I've also tested that none of these disabled locations are being hit at this point. How did you find out these places where the World Transform (XFORM) didn't match up? I'd like to try find the same thing. Thanks for the idea! Regards, Jason. -Original Message- From: Brent Fulgham [mailto:bfulg...@gmail.com] Sent: Monday, January 11, 2010 9:48 AM To: Jason Rukman Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Scrolling / redraw issue on WinCE platform Hi Jason, On Fri, Jan 8, 2010 at 11:14 AM, Jason Rukman wrote: > I'm working on a port of webKit to WinCE, and am currently encountering what appears to be a > redraw/paint issue when scrolling (horizontally, in this case) to a widget that is originally partially > off-screen (an input button in a form). The text all appears to scroll just fine, and the image of the > start of the button (which is initially on screen) is moved correctly as well through the backingStore. > However, when a paintButton is issued, the button appears in the same location on the screen > post-scroll as it does pre-scroll, i.e. in the same position and still partially off the screen, even > though the rest of the screen has scrolled. > I haven't looked at your code, but on the Windows Cairo port I have run into several cases where the GDI World Transform has not been kept in sync with the additional graphics libraries used to draw widgets. For example, I ran into some cases where the XFORM was not updated for some drawing, even though the Cairo graphics context was adjusted to take into account translation or scaling effects. It could be that your port (which probably uses *only* GDI) may be touching an area of code where some kind of coordinate transform is needed, but has not been handled at the root XFORM level, relying on CoreGraphics, Cairo, etc., to actually shift the drawing context in some fashion before drawing. Oh, there were a few places where the "SetGraphicsMode(dc, GM_ADVANCED)" was needed to ensure that coordinate transforms were being honored. Just my quick 2 cents, but might be a good place to start. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Scrolling / redraw issue on WinCE platform
Hi Jason, On Fri, Jan 8, 2010 at 11:14 AM, Jason Rukman wrote: > I'm working on a port of webKit to WinCE, and am currently encountering what > appears to be a > redraw/paint issue when scrolling (horizontally, in this case) to a widget > that is originally partially > off-screen (an input button in a form). The text all appears to scroll just > fine, and the image of the > start of the button (which is initially on screen) is moved correctly as well > through the backingStore. > However, when a paintButton is issued, the button appears in the same > location on the screen > post-scroll as it does pre-scroll, i.e. in the same position and still > partially off the screen, even > though the rest of the screen has scrolled. > I haven't looked at your code, but on the Windows Cairo port I have run into several cases where the GDI World Transform has not been kept in sync with the additional graphics libraries used to draw widgets. For example, I ran into some cases where the XFORM was not updated for some drawing, even though the Cairo graphics context was adjusted to take into account translation or scaling effects. It could be that your port (which probably uses *only* GDI) may be touching an area of code where some kind of coordinate transform is needed, but has not been handled at the root XFORM level, relying on CoreGraphics, Cairo, etc., to actually shift the drawing context in some fashion before drawing. Oh, there were a few places where the "SetGraphicsMode(dc, GM_ADVANCED)" was needed to ensure that coordinate transforms were being honored. Just my quick 2 cents, but might be a good place to start. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
Wow, much easier than I expected. :-) OK, then what about buy in on this approach? I'll even file bugs on everything I rebaseline so we can track getting things back to a correct state and/or verifying that the new baselines are correct. J On Mon, Jan 11, 2010 at 9:13 AM, Dimitri Glazkov wrote: > It's baiscally just run-webkit-tests --reset-results --pixel-tests. No > magic :) > > See run-webkit-tests --help for more info. > > BTW, Victor is working to port the rebaselining tool to > build.webkit.org. You may want to check with him -- maybe he's close > to finishing the patch. > > :DG< > > On Mon, Jan 11, 2010 at 9:06 AM, Jeremy Orlow wrote: > > On Fri, Jan 8, 2010 at 9:52 AM, Jeremy Orlow > wrote: > >> > >> Plan 3 seems like the best (and simplest) one until > the infrastructure for > >> the others (and/or a champion for fixing currently failing tests) is > >> available. > >> What would it take to go with plan 3? I guess someone needs to > rebaseline > >> everything that's currently failing, check them in, and then someone > (like > >> bdash?) needs to flip a switch on the bots...? Did I miss anything? > >> Are there instructions on how to do the rebaselining anywhere? I've > only > >> ever created pixel baselines for Chromium before (where we have a pretty > >> neat tool that pretty much does it for you). > > > > Does anyone know? > > I'm happy to do the rebaselining if someone can tell me how and we agree > to > > turn pixel tests on on the bots. > > > >> > >> On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene wrote: > >>> > >>> And one very quick, short-term solution: > >>> 3. Generate new pixel results to match the current behavior, and check > >>> them in as hypothetically correct. > >>> And of course if someone notices an existing problem and fixes it, they > >>> check in corrected images then. It doesn't help find current problems, > but > >>> those are being missed now anyway. It does let the tests be run again > >>> approximately immediately, even faster than waiting for test > expectations > >>> functionality, so we can catch regressions moving forward. > >>> - Pam > >>> > >>> On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai wrote: > > On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler wrote: > > > > On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: > > > Are we planning to run pixel tests on the build bots? > > > > If we can get them green, we should. It’s a lot of work. We need a > > volunteer to do that work. We’ve tried before. > > Two possible long-term solutions come to mind: > 1. Turn the bots orange on pixel failures. They still need fixing, but > are not as severe as text diff failures. I'm not a huge fan of this, > but > it's an option. > 2. Add in a concept of expected failures and only turn the bots red > for > *unexpected* failurs. More details on this below. > In chromium-land, there's an expectations file that lists expected > failures and allows for distinguishing different types of failures > (e.g. > IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip > the > test. Fixing the expected failures still needs doing of course, but > can be > done asynchronously. The primary advantage of this approach is that we > can > turn on pixel tests, keep the bots green and avoid further > regressions. > Would something like that make sense for WebKit as a whole? To be > clear, > we would be nearly as loathe to add tests to this file as we are about > adding them to the Skipped lists. This just provides a way forward. > While it's true that the bots used to be red more frequently with > pixel > tests turned on, for the most part, there weren't significant pixel > regressions. Now, if you run the pixel tests on a clean build, there > are a > number of failures and a very large number of hash-mismatches that are > within the failure tolerance level. > -Ojan > For reference, the format of the expectations file is something like > this: > // Fails the image diff but not the text diff. > fast/forms/foo.html = IMAGE > // Fails just the text diff. > fast/forms/bar.html = TEXT > // Fails both the image and text diffs. > fast/forms/baz.html = IMAGE+TEXT > // Skips this test (e.g. because it hangs run-webkit-tests or causes > other tests to fail). > SKIP : fast/forms/foo1.html = IMAGE > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > >>> > >>> > >>> ___ > >>> webkit-dev mailing list > >>> webkit-dev@lists.webkit.org > >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >>> > >> > > > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > h
[webkit-dev] Touch-supporting layout tests
I think it's really cool that we have some touch events-related layout tests landing in the tree. But... is there a chance we could move them to a directory that would allow easy filtering-out for ports that don't support touch events? fast/events/touch/, for instance? :DG< ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
It's baiscally just run-webkit-tests --reset-results --pixel-tests. No magic :) See run-webkit-tests --help for more info. BTW, Victor is working to port the rebaselining tool to build.webkit.org. You may want to check with him -- maybe he's close to finishing the patch. :DG< On Mon, Jan 11, 2010 at 9:06 AM, Jeremy Orlow wrote: > On Fri, Jan 8, 2010 at 9:52 AM, Jeremy Orlow wrote: >> >> Plan 3 seems like the best (and simplest) one until the infrastructure for >> the others (and/or a champion for fixing currently failing tests) is >> available. >> What would it take to go with plan 3? I guess someone needs to rebaseline >> everything that's currently failing, check them in, and then someone (like >> bdash?) needs to flip a switch on the bots...? Did I miss anything? >> Are there instructions on how to do the rebaselining anywhere? I've only >> ever created pixel baselines for Chromium before (where we have a pretty >> neat tool that pretty much does it for you). > > Does anyone know? > I'm happy to do the rebaselining if someone can tell me how and we agree to > turn pixel tests on on the bots. > >> >> On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene wrote: >>> >>> And one very quick, short-term solution: >>> 3. Generate new pixel results to match the current behavior, and check >>> them in as hypothetically correct. >>> And of course if someone notices an existing problem and fixes it, they >>> check in corrected images then. It doesn't help find current problems, but >>> those are being missed now anyway. It does let the tests be run again >>> approximately immediately, even faster than waiting for test expectations >>> functionality, so we can catch regressions moving forward. >>> - Pam >>> >>> On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler wrote: > > On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: > > Are we planning to run pixel tests on the build bots? > > If we can get them green, we should. It’s a lot of work. We need a > volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >>> ___ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
On Fri, Jan 8, 2010 at 9:52 AM, Jeremy Orlow wrote: > Plan 3 seems like the best (and simplest) one until the infrastructure for > the others (and/or a champion for fixing currently failing tests) is > available. > > What would it take to go with plan 3? I guess someone needs to rebaseline > everything that's currently failing, check them in, and then someone (like > bdash?) needs to flip a switch on the bots...? Did I miss anything? > > Are there instructions on how to do the rebaselining anywhere? I've only > ever created pixel baselines for Chromium before (where we have a pretty > neat tool that pretty much does it for you). > Does anyone know? I'm happy to do the rebaselining if someone can tell me how and we agree to turn pixel tests on on the bots. > On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene wrote: > >> And one very quick, short-term solution: >> >> 3. Generate new pixel results to match the current behavior, and check >> them in as hypothetically correct. >> >> And of course if someone notices an existing problem and fixes it, they >> check in corrected images then. It doesn't help find current problems, but >> those are being missed now anyway. It does let the tests be run again >> approximately immediately, even faster than waiting for test expectations >> functionality, so we can catch regressions moving forward. >> >> - Pam >> >> On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai wrote: >> >>> On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler wrote: >>> On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: > Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. >>> >>> >>> Two possible long-term solutions come to mind: >>> 1. Turn the bots orange on pixel failures. They still need fixing, but >>> are not as severe as text diff failures. I'm not a huge fan of this, but >>> it's an option. >>> 2. Add in a concept of expected failures and only turn the bots red for >>> *unexpected* failurs. More details on this below. >>> >>> In chromium-land, there's an expectations file that lists expected >>> failures and allows for distinguishing different types of failures (e.g. >>> IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the >>> test. Fixing the expected failures still needs doing of course, but can be >>> done asynchronously. The primary advantage of this approach is that we can >>> turn on pixel tests, keep the bots green and avoid further regressions. >>> >>> Would something like that make sense for WebKit as a whole? To be clear, >>> we would be nearly as loathe to add tests to this file as we are about >>> adding them to the Skipped lists. This just provides a way forward. >>> >>> While it's true that the bots used to be red more frequently with pixel >>> tests turned on, for the most part, there weren't significant pixel >>> regressions. Now, if you run the pixel tests on a clean build, there are a >>> number of failures and a very large number of hash-mismatches that are >>> within the failure tolerance level. >>> >>> -Ojan >>> >>> For reference, the format of the expectations file is something like >>> this: >>> >>> // Fails the image diff but not the text diff. >>> fast/forms/foo.html = IMAGE >>> >>> // Fails just the text diff. >>> fast/forms/bar.html = TEXT >>> >>> // Fails both the image and text diffs. >>> fast/forms/baz.html = IMAGE+TEXT >>> >>> // Skips this test (e.g. because it hangs run-webkit-tests or causes >>> other tests to fail). >>> SKIP : fast/forms/foo1.html = IMAGE >>> >>> ___ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PreloadScanner aggressiveness
On Fri, Jan 8, 2010 at 3:00 AM, Mike Belshe wrote: Nice testing! But for HTTP; the key seems to the pre-rendering-ready escape hatch in > DocLoader::preload. Removing this gives me most all of the benefit. The > comment says it pretty clearly: "Don't preload images or body resources > before we have something to draw. This prevents preloads from body delaying > first display when bandwidth is limited." For SPDY, there is more benefit > by continuing to preparse aggressively - I suspect this is due to the finer > grained prioritization where it can continue to send requests up without > impacting the clogged downlink channel. > Yeah, this is currently really optimized for best first display, not for total load time. In my testing that escape hatch was pretty important for first display if the case was bandwidth limited (several seconds on some major sites on 3G). It is not surprising that it may somewhat hurt total load time in high bandwidth/high latency case. Ideally we would have per-site estimate of the current bandwidth and latency values available so we could tune things like this dynamically. Any testing of changes here should consider first display times too, not just total load time. antti ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
