>
>
>> I'm curious, what would you imagine the ref test contains?
>>
>
> If I am not mistaken, the composition operations are parallel with the
> ones of SVG and Canvas (aren't they?).
> I would have attempted comparing the 3 implementations as it seems to me
> the pixels values should be the same.
On Wed, Feb 13, 2013 at 11:33 PM, Benjamin Poulain wrote:
> On Wed, Feb 13, 2013 at 11:16 PM, Dirk Pranke wrote:
>>
>> > Those changes are not harmless. There are people monitoring tests
>> > results
>> > full time in order to keep WebKit in good shape. No other part of WebKit
>> > require contin
-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>"
mailto:webkit-dev@lists.webkit.org>>
Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction
pixel-results "on the fly"
On Wed, Feb 13, 2013 at 11:27 PM,
mailto:noam.rosent...@nokia.com&g
On Wed, Feb 13, 2013 at 11:27 PM, wrote:
> Why wasn't a ref-test a better solution in this particular case?
>
> Because gaussian blurs on the GPU are not accurate, and look slightly
> different on different GPUs, but usually "close enough".
> We need a way to measure "close enough" for features
On Wed, Feb 13, 2013 at 11:16 PM, Dirk Pranke wrote:
> > Those changes are not harmless. There are people monitoring tests results
> > full time in order to keep WebKit in good shape. No other part of WebKit
> > require continuous attention.
>
> I'm sorry, but either I don't understand Dongsung's
Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction
pixel-results "on the fly"
On Wed, Feb 13, 2013 at 9:38 PM, Dongsung Huang
mailto:luxte...@company100.net>> wrote:
I like this idea. I cannot find any harm if we have this functionality.
Those changes a
On Wed, Feb 13, 2013 at 11:07 PM, Benjamin Poulain wrote:
> On Wed, Feb 13, 2013 at 9:38 PM, Dongsung Huang
> wrote:
>>
>> I like this idea. I cannot find any harm if we have this functionality.
>
>
> Those changes are not harmless. There are people monitoring tests results
> full time in order t
On Wed, Feb 13, 2013 at 9:38 PM, Dongsung Huang wrote:
> I like this idea. I cannot find any harm if we have this functionality.
>
Those changes are not harmless. There are people monitoring tests results
full time in order to keep WebKit in good shape. No other part of WebKit
require continuous
I like this idea. I cannot find any harm if we have this functionality.
When a pixel test is more succinct, we can make a pixel test. When a
'getPixel on Javascript' test is more succinct, we can make a 'getPixel'
test.
As
http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree
On Sun, Feb 10, 2013 at 1:30 AM, Ryosuke Niwa wrote:
> On Sat, Feb 9, 2013 at 5:35 PM, Dirk Pranke wrote:
>>
>> Perhaps -- and this is a tangent to this thread -- we could also
>> investigate ways of writing tests that did render pngs but told NRWT
>> to ignore them (e.g., dumpAsTextAndIgnoredIma
On Sat, Feb 9, 2013 at 5:35 PM, Dirk Pranke wrote:
> Perhaps -- and this is a tangent to this thread -- we could also
> investigate ways of writing tests that did render pngs but told NRWT
> to ignore them (e.g., dumpAsTextAndIgnoredImage() or something), or
> conveyed which parts of the image we
On Sat, Feb 9, 2013 at 1:57 AM, Benjamin Poulain wrote:
> On Sat, Feb 9, 2013 at 1:24 AM, wrote:
>>
>> I did not say they cannot be tested with the two methods suggested :) It's
>> more about a preference to move some of those decisions from the test
>> infrastructure to the test itself, but pot
Oops, forgot to reply to the list.
From: Noam Rosenthal mailto:noam.rosent...@nokia.com>>
From: ext Simon Fraser mailto:simon.fra...@apple.com>>
The existing pauseAnimation DRT API can stop an animation mid-flight, to allow
for reliable snapshotting. Why isn't this enough?
I would say that the ma
> Date: Saturday, February 9, 2013 10:57 AM
> To: Noam Rosenthal
> Cc: "rn...@webkit.org" , "webkit-dev@lists.webkit.org"
>
> Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction
> pixel-results "on the fly"
>
>&
,
"webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org>"
mailto:webkit-dev@lists.webkit.org>>
Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction
pixel-results "on the fly"
On Sat, Feb 9, 2013 at 1:24 AM,
mailto:noam.rosent...@nokia.com>
From: ext Benjamin Poulain mailto:benja...@webkit.org>>
This is the situation I am afraid with a solution where pixels would be
evaluated from JavaScript. You can test, but you lack visibility why something
is correct or incorrect. Text tests, ref-tests and pixel tests have a great
readability
On Sat, Feb 9, 2013 at 1:24 AM, wrote:
>I did not say they cannot be tested with the two methods suggested :)
> It's more about a preference to move some of those decisions from the test
> infrastructure to the test itself, but potentially those bugs could be
> tested in either way.
> Exampl
.org<mailto:webkit-dev@lists.webkit.org>"
mailto:webkit-dev@lists.webkit.org>>
Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction
pixel-results "on the fly"
On Fri, Feb 8, 2013 at 3:16 PM,
mailto:noam.rosent...@nokia.com>> wrote:
The proble
I'm not sure if this is generally known: we use [svg
document].setCurrentTime(time) in the svg/animations tests for both script
and pixel tests. The SVG animation test harness leaves a lot to be desired,
but it may be a good place to start for a more general DRT approach:
http://trac.webkit.org/bro
On Fri, Feb 8, 2013 at 4:16 PM, Benjamin Poulain wrote:
> On Fri, Feb 8, 2013 at 4:12 PM, Gregg Tavares wrote:
>
>> Can you expose a time or setTime function in DRT and some option that
>> says "let JS control the clock"?
>>
>
> Unfortunately, that only works in the simple cases.
> We could cheat
On Fri, Feb 8, 2013 at 4:12 PM, Gregg Tavares wrote:
> Can you expose a time or setTime function in DRT and some option that says
> "let JS control the clock"?
>
Unfortunately, that only works in the simple cases.
We could cheat the WebCore clock, but that would ultimately be wrong for
animation
Can you expose a time or setTime function in DRT and some option that says
"let JS control the clock"?
Then a test could do something like
layoutTestController.overridePreference("JsControlledClock", "1");
// Render 5 frames over 1 second
var frame =0;
function renderFrame() {
On Fri, Feb 8, 2013 at 3:16 PM, wrote:
> The problem with dynamic features of the web like
> animations/interactions is that they're non-deterministic, or at least a
> lot less deterministic than static features of the web like layouts.
> Ref tests, pixel tests etc. are tools built for determini
From: ext Ryosuke Niwa mailto:rn...@webkit.org>>
I'd like to propose a solution, and would welcome some feedback on whether it's
a good one...
The idea is that you would be able to programatically retrieve the current
snapshot into a canvas ImageData, and then compare the pixel results with
Ja
On Fri, Feb 8, 2013 at 11:12 AM, Ryosuke Niwa wrote:
> On Fri, Feb 8, 2013 at 5:35 AM, wrote:
>>
>> we don't currently have a solution in webkit's test infrastructure for
>> testing animations "on the fly", or in general for testing multiple image
>> results in the same test.
>> (If this was disc
On Fri, Feb 8, 2013 at 11:12 AM, Ryosuke Niwa wrote:
> I had similar thoughts but my counter "proposal" is to let DRT/WTR
> generate multiple actual results either in the form of multiple layers in
> PNG or multiple PNG images. The advantage of this latter approach is that
> we can have multiple
On Fri, Feb 8, 2013 at 5:35 AM, wrote:
> we don't currently have a solution in webkit's test infrastructure for
> testing animations "on the fly", or in general for testing multiple image
> results in the same test.
> (If this was discussed before and I'm unaware of that discussion, please
> sto
> I'd like to propose a solution, and would welcome some feedback on whether
> it's a good one...
> The idea is that you would be able to programatically retrieve the current
> snapshot into a canvas ImageData, and then compare the pixel results with
> JavaScript in the LayoutTest. Something lik
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org]
on behalf of ext Robert Kroeger [rjkro...@chromium.org]
> How would the test wait for the animation to happen? Tests that use
> timeouts seem more likely to be flaky from what
Questions inline.
On Fri, Feb 8, 2013 at 8:35 AM, wrote:
>
> Hellos
>
> we don't currently have a solution in webkit's test infrastructure for
> testing animations "on the fly", or in general for testing multiple image
> results in the same test.
I have been wishing for such a thing around how t
Hellos
we don't currently have a solution in webkit's test infrastructure for testing
animations "on the fly", or in general for testing multiple image results in
the same test.
(If this was discussed before and I'm unaware of that discussion, please stop
me here...)
This is because ImageDiff
31 matches
Mail list logo
