The existing pauseAnimation DRT API can stop an animation mid-flight, to allow 
for reliable snapshotting. Why isn't this enough?


On Feb 9, 2013, at 8:44 AM, wrote:

> Since people seem to agree that this is a good problem to solve, I've created 
> a bug for it:
> I can't promise to fix it myself right this moment as I'm spread a bit too 
> thin, but if someone wants to help or pick it up before I get to it please 
> feel free :)
> Noam
> From: ext Benjamin Poulain <>
> Date: Saturday, February 9, 2013 10:57 AM
> To: Noam Rosenthal <>
> Cc: "" <>, "" 
> <>
> Subject: Re: [webkit-dev] Testing feature suggestion: animation/interaction 
> pixel-results "on the fly"
>> 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.
>>> Examples for bugs I've encountered/reviewed and can use better in-motion 
>>> testing (note that those are specific to Qt/EFL, but I'm sure there are 
>>> tons of bugs like this that come up for Apple/Google as well)
>>> Controlling the clock and programmatically sampling the end result would 
>>> definitely make those more testable, but of course any progress in this 
>>> area would be beneficial and my preference to a canvas-based API is more of 
>>> an opinion.
>> To explain my concerns:
>> Sometime, I look at a failing test, and think: "what the f**k is this 
>> supposed to test?". Then I have to dig a ton of logs, and finally read the 
>> change to understand a the single JS statement in the whole script that make 
>> the test useful. 
>> 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, you can quickly evaluate their correctness. This 
>> is important in my opinion, I don't think we want more opaque output like 
>> the RenderTree dump.
>> I am not against your plan if the readability of the tests can be good. I'd 
>> be happy to review patches toward testing dynamic changes in webpages.
>> Benjamin
> _______________________________________________
> webkit-dev mailing list

webkit-dev mailing list

Reply via email to