presentation_time

• # wp_presentation

  The main feature of this interface is accurate presentation timing feedback to ensure smooth video playback while maintaining audio/video synchronization. Some features use the concept of a presentation clock, which is defined in the presentation.clock_id event. A content update for a wl_surface is submitted by a wl_surface.commit request. Request 'feedback' associates with the wl_surface.commit and provides feedback on the content update, particularly the final realized presentation time. When the final realized presentation time is available, e.g. after a framebuffer flip completes, the requested presentation_feedback.presented events are sent. The final presentation time can differ from the compositor's predicted display update time and the update's target time, especially when the compositor misses its target vertical blanking period.

  Requests

  • #

    destroy

    unbind from the presentation interface
    void wp_presentation_destroy(

    struct wp_presentation* wp_presentation

    )
    Informs the server that the client will no longer be using this protocol object. Existing objects created by this object are not affected.
  • #

    feedback

    request presentation feedback information
    struct wp_presentation_feedback* wp_presentation_feedback(

    struct wp_presentation* wp_presentation,

    struct wl_surface* surface /* target surface */

    )
    Request presentation feedback for the current content submission on the given surface. This creates a new presentation_feedback object, which will deliver the feedback information once. If multiple presentation_feedback objects are created for the same submission, they will all deliver the same information. For details on what information is returned, see the presentation_feedback interface.

  Events

  • #

    clock_id

    clock ID for timestamps
    uint32_t clk_id /* platform clock identifier */
    This event tells the client in which clock domain the compositor interprets the timestamps used by the presentation extension. This clock is called the presentation clock. The compositor sends this event when the client binds to the presentation interface. The presentation clock does not change during the lifetime of the client connection. The clock identifier is platform dependent. On POSIX platforms, the identifier value is one of the clockid_t values accepted by clock_gettime(). clock_gettime() is defined by POSIX.1-2001. Timestamps in this clock domain are expressed as tv_sec_hi, tv_sec_lo, tv_nsec triples, each component being an unsigned 32-bit value. Whole seconds are in tv_sec which is a 64-bit value combined from tv_sec_hi and tv_sec_lo, and the additional fractional part in tv_nsec as nanoseconds. Hence, for valid timestamps tv_nsec must be in [0, 999999999]. Note that clock_id applies only to the presentation clock, and implies nothing about e.g. the timestamps used in the Wayland core protocol input events. Compositors should prefer a clock which does not jump and is not slewed e.g. by NTP. The absolute value of the clock is irrelevant. Precision of one millisecond or better is recommended. Clients must be able to query the current clock value directly, not by asking the compositor.

  Enums

  • #

    error

    fatal presentation errors
    WP_PRESENTATION_ERROR_INVALID_TIMESTAMP /* invalid value in tv_nsec */
    WP_PRESENTATION_ERROR_INVALID_FLAG /* invalid flag */
    These fatal protocol errors may be emitted in response to illegal presentation requests.

• # wp_presentation_feedback

  A presentation_feedback object returns an indication that a wl_surface content update has become visible to the user. One object corresponds to one content update submission (wl_surface.commit). There are two possible outcomes: the content update is presented to the user, and a presentation timestamp delivered; or, the user did not see the content update because it was superseded or its surface destroyed, and the content update is discarded. Once a presentation_feedback object has delivered a 'presented' or 'discarded' event it is automatically destroyed.

  Events

  • #

    sync_output

    presentation synchronized to this output
    struct wl_output* output /* presentation output */
    As presentation can be synchronized to only one output at a time, this event tells which output it was. This event is only sent prior to the presented event. As clients may bind to the same global wl_output multiple times, this event is sent for each bound instance that matches the synchronized output. If a client has not bound to the right wl_output global at all, this event is not sent.
  • #

    presented

    the content update was displayed
    uint32_t tv_sec_hi /* high 32 bits of the seconds part of the presentation timestamp */
    uint32_t tv_sec_lo /* low 32 bits of the seconds part of the presentation timestamp */
    uint32_t tv_nsec /* nanoseconds part of the presentation timestamp */
    uint32_t refresh /* nanoseconds till next refresh */
    uint32_t seq_hi /* high 32 bits of refresh counter */
    uint32_t seq_lo /* low 32 bits of refresh counter */
    uint32_t flags /* combination of 'kind' values */
    The associated content update was displayed to the user at the indicated time (tv_sec_hi/lo, tv_nsec). For the interpretation of the timestamp, see presentation.clock_id event. The timestamp corresponds to the time when the content update turned into light the first time on the surface's main output. Compositors may approximate this from the framebuffer flip completion events from the system, and the latency of the physical display path if known. This event is preceded by all related sync_output events telling which output's refresh cycle the feedback corresponds to, i.e. the main output for the surface. Compositors are recommended to choose the output containing the largest part of the wl_surface, or keeping the output they previously chose. Having a stable presentation output association helps clients predict future output refreshes (vblank). The 'refresh' argument gives the compositor's prediction of how many nanoseconds after tv_sec, tv_nsec the very next output refresh may occur. This is to further aid clients in predicting future refreshes, i.e., estimating the timestamps targeting the next few vblanks. If such prediction cannot usefully be done, the argument is zero. If the output does not have a constant refresh rate, explicit video mode switches excluded, then the refresh argument must be zero. The 64-bit value combined from seq_hi and seq_lo is the value of the output's vertical retrace counter when the content update was first scanned out to the display. This value must be compatible with the definition of MSC in GLX_OML_sync_control specification. Note, that if the display path has a non-zero latency, the time instant specified by this counter may differ from the timestamp's. If the output does not have a concept of vertical retrace or a refresh cycle, or the output device is self-refreshing without a way to query the refresh count, then the arguments seq_hi and seq_lo must be zero.
  • #

    discarded

    the content update was not displayed
    The content update was never displayed to the user.

  Enums

  • #

    kind

    bitmask of flags in presented event
    WP_PRESENTATION_FEEDBACK_KIND_VSYNC
    WP_PRESENTATION_FEEDBACK_KIND_HW_CLOCK
    WP_PRESENTATION_FEEDBACK_KIND_HW_COMPLETION
    WP_PRESENTATION_FEEDBACK_KIND_ZERO_COPY
    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.

Copyright Info