[PATCH weston 00/10] Implement screenshot-based testing with the headless renderer

[Pekka Paalanen]

On Tue, 12 May 2015 10:47:08 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Mon, 11 May 2015 16:07:26 +0100
> Daniel Stone <daniel at fooishbar.org> wrote:
> 
> > Hi,
> > 
> > On 11 May 2015 at 13:41, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > Did you notice, that 'clientside-screenshot.png' ends up all black, if
> > > you do 'make check BACKEND=x11-backend.so'?
> > > Wonder why it does that, you're not intending to do anything
> > > backend-specific. Except the server command line arguments?
> > 
> > €10 says this is only on uncomposited X11 servers, where you require
> > Expose events ... ?
> 
> I find that hard to believe...
> 
> x11_output_repaint_shm() ->
> pixman_renderer_repaint_output() does a repaint to the shadow, then
> copy_to_hw_buffer() and just before returning it emits the
> output->frame_signal.
> 
> Output->frame_signal should lead to a call to
> weston_renderer::read_pixels, which reads from the hw_buffer, which is
> only a pixman_image_t...
> 
> So all of rendering and read_pixels should be already done when control
> returns to x11_output_repaint_shm(), so there is no room for X11 calls
> in between.
> 
> The hw_surface (hw_buffer) is created by pixman_image_create_bits()
> which is handed a pointer to a piece of memory from shmat().
> 
> Looks like screenshooting does not go through X11 protocol, so I'm
> puzzled why it doesn't seem to work. Also, the screenshooter (super+s)
> works just fine.

Seems to be a fun race somehow. If I add a sleep(1) in the test client
just before it asks the server to take a screenshot, the saved image
turns up fine instead of black.

Oh I know. The test runs before weston-desktop-shell has initialized.
That means there is no background to be shot yet.

I do not think adding the necessary infrastructure to wait for
weston-desktop-shell to come up is necessary at this point (it might
be useful later in more advanced tests). What you could do is have the
test client post a surface with know position and a known test pattern
as the content. That can reliably be expected to work.

The test still fails though, even if the captured image seems ok:

Loading reference image /home/pq/git/weston/tests/reference/internal-screenshot-00.png
Screenshot different from reference image
Clip: 50,50 20 x 20
Bytewise comparison inside clip
Mismatched image on row 50
50,0:        e        e 
50,1: ffffffff ffffffff 
50,2:       29       29 
50,3:       1b       1b 
50,4:        e        e 
50,5: ffffffff ffffffff 
50,6:       29       29 
50,7:       1b       1b 
50,8:        e        e 
50,9: ffffffff ffffffff 
50,10:       29 ffffffb2  <---
50,11:       1b ffffffae  <---
50,12:        e ffffffa9  <---
50,13: ffffffff ffffffff 
50,14:       29 ffffffa2  <---
50,15:       1b ffffffa0  <---
50,16:        e ffffff9e  <---
50,17: ffffffff ffffffff 
50,18:       29       10  <---
50,19:       1b        a  <---
Screenshot doesn't match reference image in clipped area

My guess is the comparison fails due to bugs in bpp/stride handling
etc. The saved PNG files look identical apart from the date in the
panel.


Thanks,
pq