[PATCH v1 weston 07/11] tests: Add a fadein test

[Pekka Paalanen]

On Mon, 24 Nov 2014 18:48:51 -0800
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Mon, Nov 24, 2014 at 01:19:46PM +0200, Pekka Paalanen wrote:
> > On Wed, 19 Nov 2014 15:06:22 -0800
> > Bryce Harrington <bryce at osg.samsung.com> wrote:
> > 
> > > This also serves as a proof of concept of the screen capture
> > > functionality and as a demo for snapshot-based rendering verification.
> > > 
> > > Signed-off-by: Bryce Harrington <bryce at osg.samsung.com>
> > > ---
> > >  Makefile.am         |  7 +++++-
> > >  tests/fadein-test.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 70 insertions(+), 1 deletion(-)

> > > +TEST(fadein)
> > > +{
> > > +	struct client *client;
> > > +	char basename[32];
> > > +	char *out_path;
> > > +	int i;
> > > +
> > > +	client = client_create(100, 100, 100, 100);
> > > +	assert(client);
> > > +
> > > +	for (i = 0; i < 6; i++) {
> > > +		snprintf(basename, sizeof basename, "fadein-%02d", i);
> > > +		out_path = output_filename(basename);
> > > +
> > > +		wl_test_record_screenshot(client->test->wl_test, out_path);
> > > +		client_roundtrip(client);
> > > +		free (out_path);
> > > +
> > > +		usleep(250000);
> > > +	}
> > > +
> > > +}
> > 
> > Hi,
> > 
> > where is the verification promised in the commit message? ;-)
> > 
> > I think it is bad to rely on delays/timers. We need something
> > more deterministic: a protocol to drive the (headless) repaint.
> > 
> > We probably need the headless repaint to not run on its own, but
> > strictly when requested by the test client. Additionally, we probably
> > want to carry a "page flip completion" timestamp in that request, and
> > have the compositor use the timestamp. That way the test client can
> > actually drive the in-compositor animations, because it is in control
> > of the clock and framerate.
> 
> Yes, that would definitely be helpful.
> 
> Can you elaborate on how this should be implemented?

I don't have a clear picture in my mind yet.

Client driven repaint would probably need to be a new global in the
protocol, another test extension. Exposing it would be conditional to
both the test module, and the current backend supporting it.

It is difficult to call module functions from another module, so you
likely need some function pointers in struct weston_compositor. One
module sets them, and if the other module finds them non-NULL, it knows
the other one supports client driven repaint.

But, because for starters it would be supported only by the headless
backend, which is not used for anything but testing, it's likely fine
to make the first implementation in the headless backend and always
expose it directly from there. No need to hook it up in the test module
for now.

Once we see how it works for headless, we can plan how to let other
backends support it, if needed.

> > That should make the fade-in test reliable, and it will help with
> > Presentation testing too.
> > 
> > The client driven repaint likely needs to be enabled per-test. If a
> > test attempts to enable it, but the compositor still does not advertise
> > the support(!) in protocol, the test should skip. This way real
> > hardware backends can skip these tests automatically, as they cannot
> > (or not implemented yet) support client driven repaint.
> > 
> > How would that sound?
> 
> Sure, although I suspect all tests that care about the rendered output
> will need to set this.  Unless they care only about the initial frame.

To the contrary, I would expect most tests to only care about the final
stabilised image when all animations have ended (preferably never even
started).

I think that should be perfectly implementable without client driven
repaint. Client driven repaint is only needed for timing sensitive
tests, like for animations and testing Presentation extension.

You post damage to a surface and wait for the
presentation_feedback.presented event. Then do the screenshot. Or
actually you shouldn't even need to wait, because completing a
screenshot likely requires one more repaint cycle, so shooting itself
already guarantees a repaint.


Thanks,
pq