[webkit-dev] Testing feature suggestion: animation/interaction pixel-results "on the fly"

[Benjamin Poulain]

On Fri, Feb 8, 2013 at 3:16 PM, <noam.rosenthal at nokia.com> 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 deterministic testing:
> load a file, take a snapshot, compare against a result. Testing an
> animation (or a filter) needs to feel a lot more dynamic and expressive:
> Animate green boxes, make sure that they're within a particular range at
> particular points in time".
>

The tests also have to be deterministic and comprehensive. I am afraid of
loosing both with the Render-to-Canvas approach.

Can you give concrete examples of the kind of bugs you are hunting, and why
testing cannot use the two methods suggested?


> I think that when testing some of the dynamic features it's best to create
> a minimal mechanism such as retrieving snapshot pixels, giving more power
> to the tests themselves in a dynamic language like JavaScript, rather than
> try to force the tests to fit into a predefined set of features supported
> by the DRT/WTR infrastructure. Also this would allow some differences
> between the ports, which implement animations a bit differently, without
> constant rebaselines of reference results – e.g. A heuristic animation
> timing test may stay valid across platform even if the actual animation
> implementation is different.
>

Again, can you give concrete examples of this?

Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130208/f80f3d41/attachment.html>