mutter issueshttps://gitlab.gnome.org/GNOME/mutter/-/issues2023-12-07T23:15:22Zhttps://gitlab.gnome.org/GNOME/mutter/-/issues/3101Consider switching to Cogl backend to GLES by default2023-12-07T23:15:22ZRobert Maderrobert.mader@posteo.deConsider switching to Cogl backend to GLES by defaultWhile historically GL was preferred over GLES - AFAIK mainly because of better format support - today there are multiple arguments in favor of preferring GLES:
1. GLES nowadays supports most GL features via extensions - most likely every...While historically GL was preferred over GLES - AFAIK mainly because of better format support - today there are multiple arguments in favor of preferring GLES:
1. GLES nowadays supports most GL features via extensions - most likely every one that we use (or want to use) in Mutter, in particular formats.
2. It supports `OES_EGL_image_external`, allowing drivers to e.g. support the import YUV formats directly. There is even a (probably increasing) number of format/modifier combinations that can only be supported this way. This extension will likely never be ported to GL, see 1. below.
3. We even already use that extension for secondary GPU support.
4. A number of other compositors like Weston and Sway use GLES, partly for the same reasons (YUV/multi-GPU).
5. GLES is likely to be better supported on various embedded or mobile devices while not slower for common desktop drivers. Android is certainly a factor here.
Doing the switch for Mutter would AFAIK mainly require us to ensure we make use of modern GLES extensions wherever our current GLES backend currently lacks behind the GL 3.2 one. Most importantly we need to ensure to not use our packing fallbacks.
Context:
1. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25622 (especially https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25622#note_2132110)
2. https://gitlab.gnome.org/GNOME/gtk/-/issues/6170
3. https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5509https://gitlab.gnome.org/GNOME/mutter/-/issues/2291Add support for higher bit depth offscreen framebuffers2023-09-27T09:34:27ZNaveen KumarAdd support for higher bit depth offscreen framebuffers<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
For eventual linear blending, we noticed, we need to support h...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
For eventual linear blending, we noticed, we need to support higher bit depth offscreen framebuffers, which we currently do not. i.e. add API and tests that introduce a method to allocate 2d textures (e.g. cogl_texture_2d_new*) given a passed pixel format (e.g. xrgb210101010, or fp16), and making sure things are rendered correctly to it when rendering to an offscreen.
For reference see the existing CoglOffscreen API, it takes such a texture and draws to it, however it defaults to some argb8888 variant for now.
<!--
Describe what you would like to be able to do with Mutter
that you currently cannot do.
-->
Relates to story/issue #2134 & #2253.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/mutter/-/issues/617Use Graphene2020-10-29T13:06:01ZGeorges Basile Stavracas NetoUse GrapheneMutter already ported various data types to their graphene counterparts. However, there are a few ones left to be ported:
* [x] `CoglMatrix` → `graphene_matrix_t` (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439)
* [x] `...Mutter already ported various data types to their graphene counterparts. However, there are a few ones left to be ported:
* [x] `CoglMatrix` → `graphene_matrix_t` (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439)
* [x] `ClutterPlane` → `graphene_frustum_t` (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489)
* [x] ∅ → `graphene_ray_t` (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509)
* [ ] `ClutterActorBox` → `graphene_rect_t`GNOME 3.38Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/mutter/-/issues/461Clutter & Cogl 2.02024-01-08T08:14:08ZGeorges Basile Stavracas NetoClutter & Cogl 2.0This is a tracker issue for us to keep moving and working on Clutter & Cogl 2.0 plans. Relevant links:
* https://wiki.gnome.org/Projects/Clutter/Roadmap
* https://wiki.gnome.org/Projects/Clutter/ApocalypsesThis is a tracker issue for us to keep moving and working on Clutter & Cogl 2.0 plans. Relevant links:
* https://wiki.gnome.org/Projects/Clutter/Roadmap
* https://wiki.gnome.org/Projects/Clutter/Apocalypses