Re: Add a way to get hashes of screenshots

Hi,

Not sure if this scoops some kind of award for "slowest reply to a mailing
list", but I'll answer it now.

Section 16 of the spec
("Screenshots<https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#screenshots>")
would be the right place to make this change. I'd be fine adding a
parameter to "getScreenshot" in order to determine whether a hash or a PNG
will be returned. We try and keep the driver agnostic to how the data
should be processed, so I'm uncomfortable about your second suggestion.

What additional data would you want to be returned? The actual screenshot?
If that was the case, why not do the hashing in the same process as the
test? Simply because shuttling hashes around is faster than sending
screenshots?

Cheers,

Simon


On Wed, Aug 21, 2013 at 11:35 AM, James Graham <james@hoppipolla.co.uk>wrote:

> For some use cases it is only necessary to compare screenshots for
> (in)equality. One clear example is reftests, where you take screenshots of
> two pages and consider the test to have passed if the screenshots compare
> equal. In this case it is a great deal of overhead to have to work with the
> full screenshot data all the time; it is significantly more convenient to
> work with hashes of the screenshot. Therefore it would be very useful to
> just get these hashes back from webdriver.
>
> The simplest API would either be a parameter to getScreenshot or a new
> method to return the hash. An API better specialised for reftests would
> provide the option to also return the screenshot data if the screenshot
> matched — or failed to match — one of a set of provided hashes, so that one
> could do something like (total pseudo-code):
>
> navigate(reference)
> ref_hash = getScreenshot({"hash":"only"})
> navigate(test)
> test_screenshot, test_hash = getScreenshot({"hash":"if-not-match",
>                                             "hashes":[refhash]})
>
> That isn't a specific API proposal, since I can't decide what the best API
> would look like here. But I think it gives a flavour of the kind of
> capabilities I would find useful.
>
>