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

wayland: add support for single-pixel-buffer-v1 protocol #17298

Merged
merged 3 commits into from
Dec 29, 2024

Conversation

Sunderland93
Copy link
Contributor

Description

Add support for single-pixel-buffer-v1 protocol for optimizing the use of the wl_shm 1x1 pixel case. I'm not sure I implemented the creation of a single-pixel buffer correctly in its current form, so a review is required. Also note that support for this protocol is currently available in GNOME and wlroots.

See https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/single-pixel-buffer/single-pixel-buffer-v1.xml

Related Issues

No

Related Pull Requests

No

Reviewers

@ColinKinloch

@Sunderland93 Sunderland93 marked this pull request as draft December 28, 2024 11:41
@ColinKinloch
Copy link
Contributor

ColinKinloch commented Dec 28, 2024

I think single pixel buffers are only really useful in special cases.
For example the black borders around a video in a video player can be achieved by creating a subsurface attaching a single pixel buffer and using a viewport to scale it to the window size and layering a subsurface with the video attached above it e.g. waylandsink.

It could be used instead of the splash screen to display black at the window scale.
That could be done by changing the following line to use the output of wp_single_pixel_buffer_manager_v1_create_u32_rgba_buffer

wl_surface_attach(wl->surface, buffer->wl_buffer, 0, 0);

However this would still need a fallback for compositors that don't support single pixel buffers and I'm not sure would have much of a benefit.

@LibretroAdmin LibretroAdmin marked this pull request as ready for review December 28, 2024 16:26
@Sunderland93
Copy link
Contributor Author

However this would still need a fallback for compositors that don't support single pixel buffers and I'm not sure would have much of a benefit.

Do you have any suggestions?

@ColinKinloch
Copy link
Contributor

In the wl_draw_splash_screen function check for the single pixel buffer manager. If it exists create a black single pixel buffer, otherwise do the shm checkerboard stuff.
Then attach which ever wl_buffer was created to the surface.

Also to test it you need two monitors attached or make this line always true:

if (video_monitor_index == 0 && wl_list_length (&wl->all_outputs) > 1)

@Sunderland93
Copy link
Contributor Author

@ColinKinloch latest commit works as you suggests

@ColinKinloch
Copy link
Contributor

ColinKinloch commented Dec 29, 2024

This line from #17309 should allow the single pixel buffer to be scaled at a sensible size. otherwise it will be a single pixel window:

if (wl->viewport)
wp_viewport_set_destination(wl->viewport, wl->width, wl->height);

Also if you change these to DEFAULT_WINDOWED_WIDTH and DEFAULT_WINDOWED_HEIGHT etc. the window will not be arbitrarily the size of the splash screen image:
wl->floating_width = SPLASH_WINDOW_WIDTH;
wl->floating_height = SPLASH_WINDOW_HEIGHT;

edit: It won't produce a single pixel window. The viewport is correctly sized by a previous configure event..

Copy link
Contributor

@ColinKinloch ColinKinloch left a comment

Choose a reason for hiding this comment

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

Apart from the nitpick. This seems fine to merge as is.
I'll update #17309 after.

gfx/common/wayland_common.c Outdated Show resolved Hide resolved
@Sunderland93
Copy link
Contributor Author

Thank you!

@LibretroAdmin LibretroAdmin merged commit 9ffb458 into libretro:master Dec 29, 2024
27 checks passed
@LibretroAdmin
Copy link
Contributor

Hopefully I merged these two PRs in the right order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants