[webkit-dev] Trouble running new-run-webkit-tests
I'm trying to generate baselines for a new test, using the command WebKitTools/Scripts/new-run-webkit-tests --new-baseline test I have previously done (successfully) WebKitTools/Scripts/build-webkit WebKitTools/Scripts/build-dumprendertree When I try to run the new-run-webkit-tests, it tells me that it cannot find DumpRenderTree. It was looking in WebKitBuild/ instead of WebKitBuild/Release where the executables actually were. After copying both DumpRenderTree and ImageDiff up from the Release directory, I now get a failed test because DumpRenderTree crashed, and the stack trace is full of messages like DumpRenderTree[44776:903] Failed to activate fonts: blah ... blah ... I am using the wrong work flow? Why is the build script putting executables in one place wile new-run-webkit-tests is looking for them in another place? James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Use of 'inf' values in WebKit renderer classes
I'm trying to understand how float 'inf' values are used in WebKit rendering. I'm particularly interested in a case where a very large coordinate for a rect, which gets converted to 'inf' since its true value is too large to fit in a float, is retained. The value of 'inf' can't really be used for further computation (other than perhaps to detect its 'inf'-ness), and can cause problems when passed to lower lever graphics libraries (e.g. Skia, I'm not sure how CG handles 'inf'). If we really wanted to retain 'inf' values that are usable in computation (e.g. values that could be mapped from infinity back to a finite point, such as a vanishing point for a set of parallel 3-D lines), then don't we need to keep a homogenous/projective representation for them? I can appreciate how keeping an extra coordinate for all points might be undesirable since it requires additional overhead that is only rarely used. I guess I'm trying to understand how plain 'inf' values *are actually used* in WebKit, so I can understand why we retain them. Cheers, James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Question about -webkit-transform: scale3d() when zero scale factor is used.
What is the intended behaviour if someone applies the following style to an element: -webkit-transform: scale3d(0.8, 0.8, 0) ? Right now (in Chromium and Safari) there are two different behaviours depending whether the GPU is involved or not. With gpu acceleration the objects renders properly, but stops responding to mouse events. This is due to the fact that elements with non-invertible transforms are excluded from hit testing. Without gpu acceleration, the object renders properly and continues to respond to mouse events. This is due to the fact that when makeRenderable() is called on the element's transform, it is forced to be affine and it becomes invertible in the process. So which, if either, is correct? The following quote is found at http://www.w3.org/TR/css3-2d-transforms/ In some cases, an animation might cause a transformation matrix to be singular or non-invertible. For example, an animation in which scale moves from 1 to -1. At the time when the matrix is in such a state, the transformed element is not rendered. In this case, neither behaviour seems quite consistent, since in both case the element is rendered. Then again, this is -webkit-transform, not CSS transform, so are the intended outcomes different? Cheers, James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making top-level style changes through window.internals
All of this discussion started with my wanting to write a layout test that changes pageScaleFactor, without incurring scroll bars in the process. The documentElement.style method below seems to be able to change, for example, background colour, but it doesn't seem to work for documentElement.style.overflow = hidden. Is there somewhere else the scroll bars should be suppressed? On Thu, Sep 29, 2011 at 11:44 AM, Simon Fraser simon.fra...@apple.comwrote: On Sep 29, 2011, at 8:41 AM, Adam Roben wrote: On Sep 29, 2011, at 11:37 AM, Fady Samuel wrote: pageScaleFactor is a document level CSS scaling style. Often times, we'd like to be able to apply style at the document level when writing layout tests. As far as I'm aware, there's no way to do this in javascript in a layout test? Is this correct? If so, would anyone object to exposing document-level styles to window.internals? If not there, is there anywhere else where this can be exposed for testing purposes? In the particular case of pageScaleFactor I believe we already have eventSender.scalePageBy. (I think it's on eventSender rather than layoutTestController because it was first used to simulate Safari's pinch-to-zoom feature.) Moving this feature to window.internals and adding other similar features seems fine to me. Agreed. Fady, in what other instances do you need to change document-level style? Don't forget that it's possible to change style on the 'html' element (which is the document element) via document.documentElement.style.foo =... Simon ___ 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] Trouble tracking down flaky test results ...
I'm trying to track down test results for a flaky layout test (compositing/geometry/limit-layer-bounds-transformed-overflow.html) on the Mac 10.6 bot at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html but each time I download the test results for one of the red slots (where presumably the test failed), the test is *never* in the list of failing tests (disclaimer: I haven't had to to try every set of test results, but I've randomly sampled about ten of them ...) Am I using the wrong method to find the results for a failing version of the test? James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Trouble tracking down flaky test results ...
I should add ... if I hunt through the raw directories in the results I can find the *actual* raw output, but it's not linked in via results.html (or so it seems). On Tue, Jan 24, 2012 at 12:52 PM, W. James MacLean wjmacl...@chromium.orgwrote: I'm trying to track down test results for a flaky layout test (compositing/geometry/limit-layer-bounds-transformed-overflow.html) on the Mac 10.6 bot at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html but each time I download the test results for one of the red slots (where presumably the test failed), the test is *never* in the list of failing tests (disclaimer: I haven't had to to try every set of test results, but I've randomly sampled about ten of them ...) Am I using the wrong method to find the results for a failing version of the test? James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Trouble tracking down flaky test results ...
Ahh, that explains why I was not seeing it. Thanks. James On Tue, Jan 24, 2012 at 1:13 PM, Mihai Parparita mih...@chromium.orgwrote: results.html only links unexpected failures, and this is an expected failure on Snow Leopard. Mihai On Tue, Jan 24, 2012 at 10:02 AM, W. James MacLean wjmacl...@chromium.org wrote: I should add ... if I hunt through the raw directories in the results I can find the *actual* raw output, but it's not linked in via results.html (or so it seems). On Tue, Jan 24, 2012 at 12:52 PM, W. James MacLean wjmacl...@chromium.org wrote: I'm trying to track down test results for a flaky layout test (compositing/geometry/limit-layer-bounds-transformed-overflow.html) on the Mac 10.6 bot at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html but each time I download the test results for one of the red slots (where presumably the test failed), the test is *never* in the list of failing tests (disclaimer: I haven't had to to try every set of test results, but I've randomly sampled about ten of them ...) Am I using the wrong method to find the results for a failing version of the test? James ___ 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] Trouble tracking down flaky test results ...
It took a bit of poking around to find the checkbox, but it does solve the problem. Thanks, James On Tue, Jan 24, 2012 at 1:15 PM, Ryosuke Niwa rn...@webkit.org wrote: FYI, uncheck Only unexpected results in options and results.html will show all failures. - Ryosuke On Tue, Jan 24, 2012 at 10:13 AM, Mihai Parparita mih...@chromium.orgwrote: results.html only links unexpected failures, and this is an expected failure on Snow Leopard. Mihai On Tue, Jan 24, 2012 at 10:02 AM, W. James MacLean wjmacl...@chromium.org wrote: I should add ... if I hunt through the raw directories in the results I can find the *actual* raw output, but it's not linked in via results.html (or so it seems). On Tue, Jan 24, 2012 at 12:52 PM, W. James MacLean wjmacl...@chromium.org wrote: I'm trying to track down test results for a flaky layout test (compositing/geometry/limit-layer-bounds-transformed-overflow.html) on the Mac 10.6 bot at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html but each time I download the test results for one of the red slots (where presumably the test failed), the test is *never* in the list of failing tests (disclaimer: I haven't had to to try every set of test results, but I've randomly sampled about ten of them ...) Am I using the wrong method to find the results for a failing version of the test? James ___ 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] TransformationMatrix rotation code and floating-point precision
If it's computing theta/2, perhaps the trig formulas are for converting from a quaternion to a matrix? Does it look like the matrix in the quaternion section of this page? http://en.wikipedia.org/wiki/Rotation_operator_(vector_space) On Mon, May 14, 2012 at 10:30 PM, Shawn Singh shawnsi...@chromium.orgwrote: Hi all, I'm looking at TransformationMatrix::rotate3d(rx, ry, rz). This code does something indirect, and I don't understand why. Instead of initializing each rotation using sin(theta), cos(theta), the code computes theta/2, and then uses trig identities to initialize the rotation matrix. I checked really quickly with fprintf, and it seems like we could actually gain 1-2 bits of precision if we avoid doing this, and use sin(theta) and cos(theta) directly. In the current code, more error seems to accumulate due to sin^2 (theta / 2). Squaring that value instantly increases the error inherent in the computation. I cannot think of any valid reason that this code uses those trig identities instead of directly using sin and cos. Does anyone else know why? Is this worth changing to gain some precision? On a secondary note, its also fishy that we are freely mixing floats and doubles in the rotation code. But, I don't think that is as significant error accumulation as the sin^2. Thanks, ~Shawn ___ 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] highlighting a frame
If you're just looking to draw a border, will the focus rings mechanism suffice? On Tue, Jul 10, 2012 at 1:37 AM, Patrick East patri...@bsquare.com wrote: Hello, We are working on a custom build of WebKit that will highlight a frame when the mouse moves over it (the intent is to have it draw a border around it for use with a custom input device). We have tried modifying the webcore html.css file adding in a :hover selector for frame and iframe that sets the border property, but this doesn't work correctly for embedded frames. When we test mousing over them it draws the border on the outer-most frame and not the inner frame which is what I want. Unfortunately I don't know much about the css code in WebKit, so any suggestions on how this could be achieved would be much appreciated. Thanks! Patrick East patri...@bsquare.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
