Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EGL_KHR_platform_wayland: Clarify requirements of eglSwapBuffers #205

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 23 additions & 2 deletions extensions/KHR/EGL_KHR_platform_wayland.txt
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ Status

Version

Version 2, 2014/02/18
Version 4, 2024/09/09

Number

Expand All @@ -41,7 +41,8 @@ Dependencies
20140122).

The behavior of part of this extension is different depending on whether
the EGL_EXT_buffer_age extension is also present.
the EGL_EXT_buffer_age and KHR_swap_buffers_with_damage extensions are also
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: This should be EGL_KHR_swap_buffers_with_damage.

present.

Overview

Expand Down Expand Up @@ -93,6 +94,21 @@ New Behavior
until the next buffer swap. The rationale behind this behavior is to keep
operations result accurate until the next swap.

Synchronously within the call to eglSwapBuffers the EGL implementation will
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't really belong here IMHO. I think it should be injected into the existing definition of eglSwapBuffers() using the usual pseudo-patch semantics of GL/EGL/GLX extension specifications. E.g., "Changes to Chapter 3 of the EGL 1.5 Specification (EGL Functions and Errors)

Add the following text to subsection 3.10.1 titled "Posting to a
Window" after paragraph 3 of the description of eglSwapBuffers:

"When the <surface> refers to a Wayland platform surface, <Your new language here>"

The other language in this spec should arguably be similarly inserted relative to existing spec text, but its more general in nature, so it probably isn't as important to clean that up.

invoke a series of requests on the associated wl_surface, including
attaching the new front buffer, a full surface damage via wl_surface.damage
or wl_surface.damage_buffer, and finally a wl_surface.commit.

If the EGL implementation associated a wp_linux_drm_syncobj_surface_v1
object with the surface, an acquire and a release point will be associated
with the surface prior to the commit as well.

If KHR_swap_buffers_with_damage is available, the equivalent to calling
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section shouldn't really be necessary. eglSwapBuffersWithDamageKHR() already states that it inherits all the behavior of eglSwapBuffers():

As an alternative to eglSwapBuffers use:

    EGLBoolean eglSwapBuffersWithDamageKHR (
        EGLDisplay dpy,
        EGLSurface surface,
        const EGLint *rects,
        EGLint n_rects);

    to do the same thing as eglSwapBuffers but additionally report
    a list of rectangles that define the region that has truly
    changed since the last frame.

I think after applying the above suggestion about properly inserting this language into the eglSwapBuffers() portion of the spec, this inheritance would be more naturally implied in readers' minds.

eglSwapBuffers will take place, with the exception that the damage
according to <rects> and <n_rects> may be requested by the EGL
implementation via wl_surface.damage_buffer, instead of requesting a full
damage.

Issues

1. Should this extension permit EGL_DEFAULT_DISPLAY as input to
Expand All @@ -107,6 +123,11 @@ Issues
RESOLVED. No. Wayland has no pixmap type.

Revision History
Version 4, 2024/09/09 (Jonas Ådahl)
jadahl marked this conversation as resolved.
Show resolved Hide resolved
- Clarify wl_surface commit requirements.
- Clarify wl_surface damage responsibilities.
- Add dependency on KHR_swap_buffers_with_damage

Version 3, 2022/07/14 (Kirill Chibisov)
- Clarify EGLSurface back buffer locking behavior with regards to
rendering and surface querying operations.
Expand Down