isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-12-03 13:20:41 -05:00
Code Issues Packages Projects Releases Wiki Activity
697b99ee13
mutter/src/wayland/meta-wayland-buffer.h

112 lines
4.0 KiB
C
Raw Normal View History

wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/*
* Copyright (C) 2014 Endless Mobile
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
* 02111-1307, USA.
*
* Written by:
* Jasper St. Pierre <jstpierre@mecheye.net>
*/
#ifndef META_WAYLAND_BUFFER_H
#define META_WAYLAND_BUFFER_H
wayland: Move some buffer manipulation functions to meta-wayland-buffer
2014-10-07 22:48:49 -04:00
#include <cairo.h>
wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
#include <wayland-server.h>
Clean up include macros mess The order and way include macros were structured was chaotic, with no real common thread between files. Try to tidy up the mess with some common scheme, to make things look less messy.
2018-07-10 04:36:24 -04:00
#include "cogl/cogl.h"
#include "wayland/meta-wayland-types.h"
#include "wayland/meta-wayland-egl-stream.h"
#include "wayland/meta-wayland-dma-buf.h"
wayland: Add single pixel buffer support The "single pixel buffer" Wayland protocol extension provides a way for clients to create 1x1 buffers with a single color, specified by providing the color channels (red, green and blue) as well as the alpha channel as a 32 bit unsigned integer. For now, this is turned into a 1x1 texture. Future potential improvements is to hook things up to the scanout candidate logic and turn it into a scanout capable DMA buffer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
2022-01-19 05:49:32 -05:00
#include "wayland/meta-wayland-single-pixel-buffer.h"
wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
wayland/buffer: Add 'realization' concept to buffers Instead of having a way to determine the type of a buffer, add a realization step that implicitly detects the buffer type. This makes it possible to both realize (i.e. creating needed objects from the buffer) and determine the type at the same time, which may be the only possible way (for example, the only way to know whether a buffer is a EGLStream is to create the EGLStream from it). https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-12-08 22:15:11 -05:00
typedef enum _MetaWaylandBufferType
{
META_WAYLAND_BUFFER_TYPE_UNKNOWN,
META_WAYLAND_BUFFER_TYPE_SHM,
META_WAYLAND_BUFFER_TYPE_EGL_IMAGE,
wayland/eglstream: Don't build skeleton when disabled Instead of calling no-op functions when EGLStream support isn't enabled, make it clear at the call site that EGLStream support is optional.
2018-11-06 11:09:03 -05:00
#ifdef HAVE_WAYLAND_EGLSTREAM
wayland/buffer: Add 'realization' concept to buffers Instead of having a way to determine the type of a buffer, add a realization step that implicitly detects the buffer type. This makes it possible to both realize (i.e. creating needed objects from the buffer) and determine the type at the same time, which may be the only possible way (for example, the only way to know whether a buffer is a EGLStream is to create the EGLStream from it). https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-12-08 22:15:11 -05:00
META_WAYLAND_BUFFER_TYPE_EGL_STREAM,
wayland/eglstream: Don't build skeleton when disabled Instead of calling no-op functions when EGLStream support isn't enabled, make it clear at the call site that EGLStream support is optional.
2018-11-06 11:09:03 -05:00
#endif
wayland: Add zwp_linux_dmabuf_v1 support https://bugzilla.gnome.org/show_bug.cgi?id=785262 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-07-11 11:03:26 -04:00
META_WAYLAND_BUFFER_TYPE_DMA_BUF,
wayland: Add single pixel buffer support The "single pixel buffer" Wayland protocol extension provides a way for clients to create 1x1 buffers with a single color, specified by providing the color channels (red, green and blue) as well as the alpha channel as a 32 bit unsigned integer. For now, this is turned into a 1x1 texture. Future potential improvements is to hook things up to the scanout candidate logic and turn it into a scanout capable DMA buffer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
2022-01-19 05:49:32 -05:00
META_WAYLAND_BUFFER_TYPE_SINGLE_PIXEL,
wayland/buffer: Add 'realization' concept to buffers Instead of having a way to determine the type of a buffer, add a realization step that implicitly detects the buffer type. This makes it possible to both realize (i.e. creating needed objects from the buffer) and determine the type at the same time, which may be the only possible way (for example, the only way to know whether a buffer is a EGLStream is to create the EGLStream from it). https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-12-08 22:15:11 -05:00
} MetaWaylandBufferType;
wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
struct _MetaWaylandBuffer
{
wayland: Don't unset surface->buffer when wl_buffer destroyed Don't unset the surface->buffer if the associated wl_buffer object is destroyed. The MetaWaylandBuffer doesn't really only represent a wl_buffer object, but also the data (texture) created from the given wl_buffer. Thus, for example destroying a released SHM wl_buffer should not destroy the MetaWaylandBuffer instance, because the texture may still be used. This commit also fixes a race where calc_showing would hide a window because, at the time of calculation whether it should be showing, the surface's buffer had been destroyed as described above. https://bugzilla.gnome.org/show_bug.cgi?id=762716
2016-02-26 04:47:21 -05:00
GObject parent;
wayland/buffer: Only query Wayland EGL buffer if display bound It's not allowed to call eglQueryWaylandBuffer() if the call to eglBindWaylandDisplay() failed, and will result in an assert being hit in mesa if called. Avoid that by keeping track whether we succeeded to bind, and only attempt to realize a legacy EGL wl_buffer if binding succeeded. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
2022-05-13 15:51:53 -04:00
MetaWaylandCompositor *compositor;
wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
struct wl_resource *resource;
struct wl_listener destroy_listener;
wayland/surface: Overhaul handling of buffer use count Move the use count from a separate MetaWaylandBufferRef struct to the MetaWaylandBuffer class, and remove the former. The buffer use count is now incremented already in meta_wayland_surface_commit, since the Wayland protocol defines the buffer to be in use by the compositor at that point. If the buffer attachment ends up being dropped again before it is applied to the surface state (e.g. because another buffer is committed to a synchronized sub-surface before the parent surface is committed), the use count is now decremented, and a buffer release event is sent if the use count drops to 0. Buffer release events were previously incorrectly not sent under these circumstances. Test case: Run the weston-subsurfaces demo with the -r1 and/or -t1 command line parameter. Resize the window. Before this change, weston-subsurfaces would freeze or abort after a few resize operations, because mutter failed to send release events and the client ran out of usable buffers. v2: * Handle NULL priv->buffer_ref in meta_wayland_cursor_surface_apply_state. v3: * Remove MetaWaylandBufferRef altogether, move the use count tracking to MetaWaylandBuffer itself. Much simpler, and doesn't run into lifetime issues when mutter shuts down. v4: * Warn if use count isn't 0 in meta_wayland_buffer_finalize. * Keep pending_buffer_resource_destroyed for attached but not yet committed buffers. If the client attaches a buffer and then destroys it before commit, we ignore the buffer attachement, same as before this MR. v5: * Rebase on top of new commit which splits up surface->texture. * MetaWaylandSurfaceState::buffer can only be non-NULL if ::newly_attached is TRUE, simplify accordingly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
2022-06-22 12:43:11 -04:00
unsigned int use_count;
wayland: Add support for EGL_WAYLAND_Y_INVERTED_WL Add support for inverted Y Wayland buffers. OpenGL textures are by default inverted, so adding support for EGL_WAYLAND_Y_INVERTED_WL effectively means adding support for non-inverted, which makes the MetaShapedTexture apply a transformation when drawing only when querying EGL_WAYLAND_Y_INVERTED_WL resulted in the response "EGL_FALSE". https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:44:27 -04:00
gboolean is_y_inverted;
wayland: Add support for EGLStream client buffers This commit adds for a new type of buffer being attached to a Wayland surface: buffers from an EGLStream. These buffers behave very differently from regular Wayland buffers; instead of each buffer reperesenting an actual frame, the same buffer is attached over and over again, and EGL API is used to switch the content of the OpenGL texture associated with the buffer attached. It more or less side-tracks the Wayland buffer handling. It is implemented by creating a MetaWaylandEglStream object, dealing with the EGLStream state. The lifetime of the MetaWaylandEglStream is tied to the texture object (CoglTexture), which is referenced-counted and owned by both the actors and the MetaWaylandBuffer. When the buffer is reattached and committed, the EGLStream is triggered to switch the content of the associated texture to the new content. This means that one cannot keep old texture content around without copying, so any feature relying on that will effectively be broken. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:59:09 -04:00
wayland/buffer: Add 'realization' concept to buffers Instead of having a way to determine the type of a buffer, add a realization step that implicitly detects the buffer type. This makes it possible to both realize (i.e. creating needed objects from the buffer) and determine the type at the same time, which may be the only possible way (for example, the only way to know whether a buffer is a EGLStream is to create the EGLStream from it). https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-12-08 22:15:11 -05:00
MetaWaylandBufferType type;
wayland: Move surface texture ownership to MetaWaylandSurface Prior to this commit, MetaWaylandSurface held a reference to MetaWaylandBuffer, who owned the texture drawn by the surface. When switching buffer, the texture change with it. This is problematic when dealing with SHM buffer damage management, as when having one texture per buffer, damaged regions uploaded to one, will not follow along to the next one attached. It also wasted GPU memory as there would be one texture per buffer, instead of one one texture per surface. Instead, move the texture ownership to MetaWaylandSurface, and have the SHM buffer damage management update the surface texture. This ensures damage is processed properly, and that we won't end up with stale texture content when doing partial texture uploads. If the same SHM buffer is attached to multiple surfaces, each surface will get their own copy, and damage is tracked and uploaded separately. Non-SHM types of buffers still has their own texture reference, as the texture is just a representation of the GPU memory associated with the buffer. When such a buffer is attached to a surface, instead the surface just gets a reference to that texture, instead of a separately allocated one. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
2019-02-08 05:46:48 -05:00
struct {
CoglTexture *texture;
} egl_image;
wayland/eglstream: Don't build skeleton when disabled Instead of calling no-op functions when EGLStream support isn't enabled, make it clear at the call site that EGLStream support is optional.
2018-11-06 11:09:03 -05:00
#ifdef HAVE_WAYLAND_EGLSTREAM
wayland: Add support for EGLStream client buffers This commit adds for a new type of buffer being attached to a Wayland surface: buffers from an EGLStream. These buffers behave very differently from regular Wayland buffers; instead of each buffer reperesenting an actual frame, the same buffer is attached over and over again, and EGL API is used to switch the content of the OpenGL texture associated with the buffer attached. It more or less side-tracks the Wayland buffer handling. It is implemented by creating a MetaWaylandEglStream object, dealing with the EGLStream state. The lifetime of the MetaWaylandEglStream is tied to the texture object (CoglTexture), which is referenced-counted and owned by both the actors and the MetaWaylandBuffer. When the buffer is reattached and committed, the EGLStream is triggered to switch the content of the associated texture to the new content. This means that one cannot keep old texture content around without copying, so any feature relying on that will effectively be broken. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:59:09 -04:00
struct {
MetaWaylandEglStream *stream;
wayland: Move surface texture ownership to MetaWaylandSurface Prior to this commit, MetaWaylandSurface held a reference to MetaWaylandBuffer, who owned the texture drawn by the surface. When switching buffer, the texture change with it. This is problematic when dealing with SHM buffer damage management, as when having one texture per buffer, damaged regions uploaded to one, will not follow along to the next one attached. It also wasted GPU memory as there would be one texture per buffer, instead of one one texture per surface. Instead, move the texture ownership to MetaWaylandSurface, and have the SHM buffer damage management update the surface texture. This ensures damage is processed properly, and that we won't end up with stale texture content when doing partial texture uploads. If the same SHM buffer is attached to multiple surfaces, each surface will get their own copy, and damage is tracked and uploaded separately. Non-SHM types of buffers still has their own texture reference, as the texture is just a representation of the GPU memory associated with the buffer. When such a buffer is attached to a surface, instead the surface just gets a reference to that texture, instead of a separately allocated one. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
2019-02-08 05:46:48 -05:00
CoglTexture *texture;
wayland: Add support for EGLStream client buffers This commit adds for a new type of buffer being attached to a Wayland surface: buffers from an EGLStream. These buffers behave very differently from regular Wayland buffers; instead of each buffer reperesenting an actual frame, the same buffer is attached over and over again, and EGL API is used to switch the content of the OpenGL texture associated with the buffer attached. It more or less side-tracks the Wayland buffer handling. It is implemented by creating a MetaWaylandEglStream object, dealing with the EGLStream state. The lifetime of the MetaWaylandEglStream is tied to the texture object (CoglTexture), which is referenced-counted and owned by both the actors and the MetaWaylandBuffer. When the buffer is reattached and committed, the EGLStream is triggered to switch the content of the associated texture to the new content. This means that one cannot keep old texture content around without copying, so any feature relying on that will effectively be broken. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:59:09 -04:00
} egl_stream;
wayland/eglstream: Don't build skeleton when disabled Instead of calling no-op functions when EGLStream support isn't enabled, make it clear at the call site that EGLStream support is optional.
2018-11-06 11:09:03 -05:00
#endif
wayland: Add zwp_linux_dmabuf_v1 support https://bugzilla.gnome.org/show_bug.cgi?id=785262 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-07-11 11:03:26 -04:00
struct {
MetaWaylandDmaBufBuffer *dma_buf;
wayland: Move surface texture ownership to MetaWaylandSurface Prior to this commit, MetaWaylandSurface held a reference to MetaWaylandBuffer, who owned the texture drawn by the surface. When switching buffer, the texture change with it. This is problematic when dealing with SHM buffer damage management, as when having one texture per buffer, damaged regions uploaded to one, will not follow along to the next one attached. It also wasted GPU memory as there would be one texture per buffer, instead of one one texture per surface. Instead, move the texture ownership to MetaWaylandSurface, and have the SHM buffer damage management update the surface texture. This ensures damage is processed properly, and that we won't end up with stale texture content when doing partial texture uploads. If the same SHM buffer is attached to multiple surfaces, each surface will get their own copy, and damage is tracked and uploaded separately. Non-SHM types of buffers still has their own texture reference, as the texture is just a representation of the GPU memory associated with the buffer. When such a buffer is attached to a surface, instead the surface just gets a reference to that texture, instead of a separately allocated one. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
2019-02-08 05:46:48 -05:00
CoglTexture *texture;
wayland: Add zwp_linux_dmabuf_v1 support https://bugzilla.gnome.org/show_bug.cgi?id=785262 Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-07-11 11:03:26 -04:00
} dma_buf;
wayland: Add single pixel buffer support The "single pixel buffer" Wayland protocol extension provides a way for clients to create 1x1 buffers with a single color, specified by providing the color channels (red, green and blue) as well as the alpha channel as a 32 bit unsigned integer. For now, this is turned into a 1x1 texture. Future potential improvements is to hook things up to the scanout candidate logic and turn it into a scanout capable DMA buffer. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
2022-01-19 05:49:32 -05:00
struct {
MetaWaylandSinglePixelBuffer *single_pixel_buffer;
CoglTexture *texture;
} single_pixel;
onscreen/native: Handle unexpected scanout failures async We test direct client buffer scanout using a TEST_ONLY commit on atomic, and with various conditions in non-atomic, but if we end up failing to actually commit despite this, handle the fallout asynchronously. What this means is that we'll reschedule a new frame immediately. For this to work, the same scanout buffer needs to be avoided for the same CRTC. This is done by using the newly added signal on the CoglScanout object to let the MetaWaylandBuffer object mark the current buffer as non-working for the onsrceen that it failed on. This allows to re-try buffers on the same onscreen when new ones are attached. This queues a full damage, since we consumed the qeued redraw rect. The redraw rect wasn't lost - it was accumulated to make sure the whole primary plane was redrawed according to the damage region, whenever we would end up no longer doing direct scanout, but this accumulation only works when we're not intentionally stopping to scanout. For now, lets just damage the whole view, it's just an graceful fallback in response to an unexpected error anyway. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
2022-06-10 13:51:56 -04:00
GHashTable *tainted_scanout_onscreens;
wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
};
wayland: Don't unset surface->buffer when wl_buffer destroyed Don't unset the surface->buffer if the associated wl_buffer object is destroyed. The MetaWaylandBuffer doesn't really only represent a wl_buffer object, but also the data (texture) created from the given wl_buffer. Thus, for example destroying a released SHM wl_buffer should not destroy the MetaWaylandBuffer instance, because the texture may still be used. This commit also fixes a race where calc_showing would hide a window because, at the time of calculation whether it should be showing, the surface's buffer had been destroyed as described above. https://bugzilla.gnome.org/show_bug.cgi?id=762716
2016-02-26 04:47:21 -05:00
#define META_TYPE_WAYLAND_BUFFER (meta_wayland_buffer_get_type ())
G_DECLARE_FINAL_TYPE (MetaWaylandBuffer, meta_wayland_buffer,
META, WAYLAND_BUFFER, GObject);
wayland/buffer: Only query Wayland EGL buffer if display bound It's not allowed to call eglQueryWaylandBuffer() if the call to eglBindWaylandDisplay() failed, and will result in an assert being hit in mesa if called. Avoid that by keeping track whether we succeeded to bind, and only attempt to realize a legacy EGL wl_buffer if binding succeeded. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
2022-05-13 15:51:53 -04:00
MetaWaylandBuffer * meta_wayland_buffer_from_resource (MetaWaylandCompositor *compositor,
struct wl_resource *resource);
cursor-renderer/native: Fetch instead of pass wl_buffer when realizing This is the next step in centralizing the cursor sprite hw sprite realization paths. https://gitlab.gnome.org/GNOME/mutter/issues/77
2018-05-02 06:27:02 -04:00
struct wl_resource * meta_wayland_buffer_get_resource (MetaWaylandBuffer *buffer);
wayland: Always realize buffers at surface commit time Clients using EGLStream-backed buffers will expect the stream to be functional after wl_surface::attach(). That means the compositor-side stream must be created and a consumer attached to it. To resolve the above, this change realizes buffers even when the attach operation is deferred (e.g. synchronized subsurfaces). https://bugzilla.gnome.org/show_bug.cgi?id=782575
2017-05-05 21:41:51 -04:00
gboolean meta_wayland_buffer_is_realized (MetaWaylandBuffer *buffer);
gboolean meta_wayland_buffer_realize (MetaWaylandBuffer *buffer);
wayland: Make MetaWaylandBuffer handle texture generation itself Don't rely on the Cogl layer having Wayland specific paths by determining the buffer type and creating the EGLImage ourself, while using the newly exposed CoglTexture from EGLImage API. This changes the API used by MetaWaylandSurface to make the MetaWaylandBuffer API be aware when the buffer is being attached. For SHM and EGL buffers, only the first time it is attached will result in a new texture being allocated, but later for EGLStream's, more logic on every attach is needed. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:35:29 -04:00
gboolean meta_wayland_buffer_attach (MetaWaylandBuffer *buffer,
wayland: Move surface texture ownership to MetaWaylandSurface Prior to this commit, MetaWaylandSurface held a reference to MetaWaylandBuffer, who owned the texture drawn by the surface. When switching buffer, the texture change with it. This is problematic when dealing with SHM buffer damage management, as when having one texture per buffer, damaged regions uploaded to one, will not follow along to the next one attached. It also wasted GPU memory as there would be one texture per buffer, instead of one one texture per surface. Instead, move the texture ownership to MetaWaylandSurface, and have the SHM buffer damage management update the surface texture. This ensures damage is processed properly, and that we won't end up with stale texture content when doing partial texture uploads. If the same SHM buffer is attached to multiple surfaces, each surface will get their own copy, and damage is tracked and uploaded separately. Non-SHM types of buffers still has their own texture reference, as the texture is just a representation of the GPU memory associated with the buffer. When such a buffer is attached to a surface, instead the surface just gets a reference to that texture, instead of a separately allocated one. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
2019-02-08 05:46:48 -05:00
CoglTexture **texture,
wayland: Make MetaWaylandBuffer handle texture generation itself Don't rely on the Cogl layer having Wayland specific paths by determining the buffer type and creating the EGLImage ourself, while using the newly exposed CoglTexture from EGLImage API. This changes the API used by MetaWaylandSurface to make the MetaWaylandBuffer API be aware when the buffer is being attached. For SHM and EGL buffers, only the first time it is attached will result in a new texture being allocated, but later for EGLStream's, more logic on every attach is needed. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:35:29 -04:00
GError **error);
wayland: Add support for EGLStream client buffers This commit adds for a new type of buffer being attached to a Wayland surface: buffers from an EGLStream. These buffers behave very differently from regular Wayland buffers; instead of each buffer reperesenting an actual frame, the same buffer is attached over and over again, and EGL API is used to switch the content of the OpenGL texture associated with the buffer attached. It more or less side-tracks the Wayland buffer handling. It is implemented by creating a MetaWaylandEglStream object, dealing with the EGLStream state. The lifetime of the MetaWaylandEglStream is tied to the texture object (CoglTexture), which is referenced-counted and owned by both the actors and the MetaWaylandBuffer. When the buffer is reattached and committed, the EGLStream is triggered to switch the content of the associated texture to the new content. This means that one cannot keep old texture content around without copying, so any feature relying on that will effectively be broken. https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:59:09 -04:00
CoglSnippet * meta_wayland_buffer_create_snippet (MetaWaylandBuffer *buffer);
wayland/surface: Overhaul handling of buffer use count Move the use count from a separate MetaWaylandBufferRef struct to the MetaWaylandBuffer class, and remove the former. The buffer use count is now incremented already in meta_wayland_surface_commit, since the Wayland protocol defines the buffer to be in use by the compositor at that point. If the buffer attachment ends up being dropped again before it is applied to the surface state (e.g. because another buffer is committed to a synchronized sub-surface before the parent surface is committed), the use count is now decremented, and a buffer release event is sent if the use count drops to 0. Buffer release events were previously incorrectly not sent under these circumstances. Test case: Run the weston-subsurfaces demo with the -r1 and/or -t1 command line parameter. Resize the window. Before this change, weston-subsurfaces would freeze or abort after a few resize operations, because mutter failed to send release events and the client ran out of usable buffers. v2: * Handle NULL priv->buffer_ref in meta_wayland_cursor_surface_apply_state. v3: * Remove MetaWaylandBufferRef altogether, move the use count tracking to MetaWaylandBuffer itself. Much simpler, and doesn't run into lifetime issues when mutter shuts down. v4: * Warn if use count isn't 0 in meta_wayland_buffer_finalize. * Keep pending_buffer_resource_destroyed for attached but not yet committed buffers. If the client attaches a buffer and then destroys it before commit, we ignore the buffer attachement, same as before this MR. v5: * Rebase on top of new commit which splits up surface->texture. * MetaWaylandSurfaceState::buffer can only be non-NULL if ::newly_attached is TRUE, simplify accordingly. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
2022-06-22 12:43:11 -04:00
void meta_wayland_buffer_inc_use_count (MetaWaylandBuffer *buffer);
void meta_wayland_buffer_dec_use_count (MetaWaylandBuffer *buffer);
wayland: Add support for EGL_WAYLAND_Y_INVERTED_WL Add support for inverted Y Wayland buffers. OpenGL textures are by default inverted, so adding support for EGL_WAYLAND_Y_INVERTED_WL effectively means adding support for non-inverted, which makes the MetaShapedTexture apply a transformation when drawing only when querying EGL_WAYLAND_Y_INVERTED_WL resulted in the response "EGL_FALSE". https://bugzilla.gnome.org/show_bug.cgi?id=773629
2016-10-20 03:44:27 -04:00
gboolean meta_wayland_buffer_is_y_inverted (MetaWaylandBuffer *buffer);
wayland: Move some buffer manipulation functions to meta-wayland-buffer
2014-10-07 22:48:49 -04:00
void meta_wayland_buffer_process_damage (MetaWaylandBuffer *buffer,
wayland: Move surface texture ownership to MetaWaylandSurface Prior to this commit, MetaWaylandSurface held a reference to MetaWaylandBuffer, who owned the texture drawn by the surface. When switching buffer, the texture change with it. This is problematic when dealing with SHM buffer damage management, as when having one texture per buffer, damaged regions uploaded to one, will not follow along to the next one attached. It also wasted GPU memory as there would be one texture per buffer, instead of one one texture per surface. Instead, move the texture ownership to MetaWaylandSurface, and have the SHM buffer damage management update the surface texture. This ensures damage is processed properly, and that we won't end up with stale texture content when doing partial texture uploads. If the same SHM buffer is attached to multiple surfaces, each surface will get their own copy, and damage is tracked and uploaded separately. Non-SHM types of buffers still has their own texture reference, as the texture is just a representation of the GPU memory associated with the buffer. When such a buffer is attached to a surface, instead the surface just gets a reference to that texture, instead of a separately allocated one. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
2019-02-08 05:46:48 -05:00
CoglTexture *texture,
wayland: Move some buffer manipulation functions to meta-wayland-buffer
2014-10-07 22:48:49 -04:00
cairo_region_t *region);
wayland: Add API to acquire a CoglScanout from a surface This will check whether the current backing buffer is compatible with the primary plane of the passed CoglOnscreen. Since this will extend the time before a buffer is released, the MetaWaylandBufferRef is swapped and orphaned if a new buffer is committed before the previous one was released. It'll eventually be released, usually by the next page flip callback. Currently implemented for EGLImage and DMA-BUF buffer types. https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
2019-09-12 05:44:59 -04:00
CoglScanout * meta_wayland_buffer_try_acquire_scanout (MetaWaylandBuffer *buffer,
CoglOnscreen *onscreen);
wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
wayland/shm: Advertise support for RGB565 Doesn't hurt to support it, could save memory bandwidth would any client use it without degrading visual quality. https://gitlab.gnome.org/GNOME/mutter/merge_requests/804
2019-09-18 10:18:58 -04:00
void meta_wayland_init_shm (MetaWaylandCompositor *compositor);
wayland: Put the MetaWaylandBuffer implementation in a new file
2014-10-07 22:39:00 -04:00
#endif /* META_WAYLAND_BUFFER_H */
Reference in New Issue Copy Permalink