[PATCH v1 weston 06/11] tests: Add screenshot recording to weston-test
ppaalanen at gmail.com
Wed Nov 26 03:08:59 PST 2014
On Tue, 25 Nov 2014 09:11:39 -0600
Derek Foreman <derekf at osg.samsung.com> wrote:
> On 25/11/14 03:53 AM, Pekka Paalanen wrote:
> > On Mon, 24 Nov 2014 15:20:35 -0800
> > Bryce Harrington <bryce at osg.samsung.com> wrote:
> >> On Mon, Nov 24, 2014 at 04:31:01PM -0600, Derek Foreman wrote:
> >>> On 24/11/14 05:01 AM, Pekka Paalanen wrote:
> >>>> On Wed, 19 Nov 2014 15:06:21 -0800
> >>>> Bryce Harrington <bryce at osg.samsung.com> wrote:
> >>>>> From: Derek Foreman <derekf at osg.samsung.com>
> >>>>> Adds wl_test_record_screenshot() to weston test. This commit also
> >>>>> adds a dependency on cairo to weston-test to use it for writing PNG
> >>>>> files.
> >>>>> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=83981
> >>>>> Signed-off-by: Bryce Harrington <bryce at osg.samsung.com>
> >>>> Hi,
> >>>> could we use a wl_shm-based wl_buffer instead of a file, please?
> > Btw. I would imagine that it would be useful to have a check function
> > like:
> > bool check_solid_color(image, rectangle, color, fuzz?)
> > which would check that the rectangle sub-region of the image is of that
> > solid color (with appropriate fuzz). That way we don't need reference
> > images in git for everything.
> What's fuzz exactly? Each pixel can be within +-fuzz/2 on each color
> component and still be a match? a fuzz of 256 would match everything?
> Or would fuzz be to allow a certain percentage of pixels to deviate (ie:
> the bar with the clock and the icons on it being tested against red...)
I always thought the fuzz would be a threshold on color value
difference for fail/pass. Even one failing pixel would fail the whole
Bryce listed lots of things related to fuzz and where the valid
inaccuracies may come from. I think we should be able to avoid geometry
rasterization differences by leaving a margin between the checked rect
and the edge of the (assumed) color region. The only thing we'd need to
account for is rounding in blending and color values.
That should get us pretty far. When we come up with tests where it's
not enough, we can think about it again.
Luckily Wayland does not include a drawing protocol. :-)
In the end, the fuzz can be defined any way you see appropriate.
> >> Even with it enabled, if we keep png generation client-side then we're
> >> not going to risk interfering with the compositor. Although, maybe some
> >> tests link in some compositor code and could hit the issue... not sure.
> >> At least here the scope of the problem will be limited to the one test.
> >> And there's probably a few paths to solve it.
> > Linking to Cairo in the test clients is fine. By definition, that is
> > client code.
> > We have some tests that include server code IIRC, but those are not
> > test clients, and do not run with an actual server, so you wouldn't be
> > screenshooting there anyway.
> As eager as I am to not use libpng directly it's not that big deal, and
> I have done it before. I think I can see wanting to have a test client
> that uses GL for its own rendering, and if using cairo for screenshots
> makes that unworkable I'll look silly later for being lazy now.
Ah no, Cairo alone does not prevent using GL. I... uh, huh!
Hmm. libcairo.so when built with cairo-gl support does indeed link to
libGL.so. I didn't realize that, for some reason I imagined there was
But I still believe it should be ok to use cairo-image with any flavour
Now I'm not completely sure why, though...
> We're probably better off just ditching cairo entirely here (like Bill
> suggested in the first place. yeah, hi, sorry. ;)
I'd like to think we don't need to ditch Cairo. I might suggest to just
stick with Cairo, use cairo-image as much as you want, and see if
anything breaks. We can fix it later, too.
Like Bryce said, most distros don't ship Cairo with GL enabled. If we
use Cairo and GL, and it explodes because someone built Cairo with a
differen GL flavour support, I think we could even report that as bug
in Cairo upstream.
More information about the wayland-devel