1 Commits (dd4cd33f189be8a1f8e3f691b29ff57215fcab96)

Author	SHA1	Message	Date
Pekka Paalanen	7e62d25257	protocol: add presentation extension v5 ... Add accurate presentation timing features to Wayland: queueing and feedback. This specification is based on the draft written by Frederic Plourde <frederic.plourde@collabora.co.uk> and redesigned by Pekka Paalanen. The RFC v2 version is from http://lists.freedesktop.org/archives/wayland-devel/2014-January/012988.html Changes in v3: * associate presentation time to current surface contents This implements the suggestion from http://lists.freedesktop.org/archives/wayland-devel/2014-February/013066.html which prevents surface content from jumping backwards in time if a client retroactively queues an update with a target time in the past. * use 64-bit tv_sec in presentation The time_t type used in struct timespec could be almost anything. POSIX probably defines it to be an integer, but not the size. Apparently it is usually 'long', which makes it 64-bit on x86_64. To be able to fully represent timespec values returned by clock_gettime, change the protocol to use 64 bits for the tv_sec part. * define an error for invalid tv_nsec This allow us to rely on the normalized timestamp form. * define some interactions with sub-surfaces Sub-surface cached state updates (synchronized mode) are designed especially for resizing. As queued updates are not meant to produce any resizing-like effects, they also do not trigger any sub-surface operations. * add sub-headings as xml comments * queued update cannot map Because before mapping, the surface has no main output assigned. An immediate commit is needed anyway, to be able to set all the surface state, which a queued update cannot touch. * frame callbacks are not queued It is not known when queueing frame callbacks would be useful. Changes in v4: * remove mentions of the queuing feature The specification has been split and the queuing feature will be added back in another version of the extension. * add flags argument to 'presented' event Describe the nature of how the update was presented to screen and the characteristics of the feedback information. No flags have been defined for now. * add a protocol error code for invalid flags Changes in v5: * remove the destroy method for the feedback object The protocol object should instead be automatically destroyed after a 'presented' or 'discarded' event has been triggered. * some grammatical corrections to the specification [Louis-Francis Ratté-Boulianne: split the spec in two parts] Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> v3 Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>	11 years ago