diff options
Diffstat (limited to 'stable/presentation-time')
| -rw-r--r-- | stable/presentation-time/presentation-time.xml | 72 |
1 files changed, 36 insertions, 36 deletions
diff --git a/stable/presentation-time/presentation-time.xml b/stable/presentation-time/presentation-time.xml index d1731f0..b666664 100644 --- a/stable/presentation-time/presentation-time.xml +++ b/stable/presentation-time/presentation-time.xml @@ -159,43 +159,43 @@ These flags provide information about how the presentation of the related content update was done. The intent is to help clients assess the reliability of the feedback and the visual - quality with respect to possible tearing and timings. The - flags are: - - VSYNC: - The presentation was synchronized to the "vertical retrace" by - the display hardware such that tearing does not happen. - Relying on user space scheduling is not acceptable for this - flag. If presentation is done by a copy to the active - frontbuffer, then it must guarantee that tearing cannot - happen. - - HW_CLOCK: - The display hardware provided measurements that the hardware - driver converted into a presentation timestamp. Sampling a - clock in user space is not acceptable for this flag. - - HW_COMPLETION: - The display hardware signalled that it started using the new - image content. The opposite of this is e.g. a timer being used - to guess when the display hardware has switched to the new - image content. - - ZERO_COPY: - The presentation of this update was done zero-copy. This means - the buffer from the client was given to display hardware as - is, without copying it. Compositing with OpenGL counts as - copying, even if textured directly from the client buffer. - Possible zero-copy cases include direct scanout of a - fullscreen surface and a surface on a hardware overlay. + quality with respect to possible tearing and timings. </description> - <entry name="vsync" value="0x1" summary="presentation was vsync'd"/> - <entry name="hw_clock" value="0x2" - summary="hardware provided the presentation timestamp"/> - <entry name="hw_completion" value="0x4" - summary="hardware signalled the start of the presentation"/> - <entry name="zero_copy" value="0x8" - summary="presentation was done zero-copy"/> + <entry name="vsync" value="0x1"> + <description summary="presentation was vsync'd"> + The presentation was synchronized to the "vertical retrace" by + the display hardware such that tearing does not happen. + Relying on user space scheduling is not acceptable for this + flag. If presentation is done by a copy to the active + frontbuffer, then it must guarantee that tearing cannot + happen. + </description> + </entry> + <entry name="hw_clock" value="0x2"> + <description summary="hardware provided the presentation timestamp"> + The display hardware provided measurements that the hardware + driver converted into a presentation timestamp. Sampling a + clock in user space is not acceptable for this flag. + </description> + </entry> + <entry name="hw_completion" value="0x4"> + <description summary="hardware signalled the start of the presentation"> + The display hardware signalled that it started using the new + image content. The opposite of this is e.g. a timer being used + to guess when the display hardware has switched to the new + image content. + </description> + </entry> + <entry name="zero_copy" value="0x8"> + <description summary="presentation was done zero-copy"> + The presentation of this update was done zero-copy. This means + the buffer from the client was given to display hardware as + is, without copying it. Compositing with OpenGL counts as + copying, even if textured directly from the client buffer. + Possible zero-copy cases include direct scanout of a + fullscreen surface and a surface on a hardware overlay. + </description> + </entry> </enum> <event name="presented"> |