The commit also moves certain functions from the private header
as they are not used anywhere else and removes COGL_EXPORT
when the function is supposed to be private and is not used outside of
cogl
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3437>
We will also require GL_OES_texture_half_float and GLES 3.0 to enable
COGL_FEATURE_ID_TEXTURE_HALF_FLOAT. This gives us float types and makes
it possible to read pixels from framebuffers with internal floating
point formats (into float, half is never supported).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
This implementation is copied from mesa.
It uses x86_64 assembler on CPUs where it's supported, otherwise falls
back on a software implementation (cogl-soft-float.c). It's intended to
be used for packing and unpacking f16 format bitmaps.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
The implementation comes from mesa, which came from Berkeley SoftFloat
3e Library.
The software float implementation will be used to convert from and to
half floating point pixel format bitmaps, when no the CPU isn't capable
of the conversion.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
The type of the intermediate medium for storing pixel channels is
changed from "is 8 or 16 bit" to an enum, and switch cases. This doesn't
add support for anything, but will make adding a "float" medium type
less intrusive.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
There is no internal fp16 format which has no alpha which means we would
get garbage alpha when reading the framebuffer directly. We have to use
the packing/unpacking to always get the alpha of 1.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
Which gltype and glformat are allowed for a given gl framebuffer depends
on the internal gl framebuffer format. Either the format we want to read
into matches the gltype, glformat and doesn't need CPU packing from
another format or we have to use a tmp buffer with a format that matches
the GL requirements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3441>
Sometimes it's useful to combine the description from multiple places.
For example, a subsequent commit will add the output name as the first
thing to the frame clock span descriptions, leaving the rest of the
description with complex checks unchanged.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3417>
Using sized internal formats is required to make sure we actually get
the precision that we want.
The formats should also be renderable, otherwise they can not be used as
a framebuffer attachment. For GLES we have to check for a bunch of
extensions and fall back to internal formats with more bits when they
are not available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
In GLES 2.0 the required color-renderable formats to support to not
include 8bpc RGB/RGBA formats. The extension adds this requirement and
makes GLES 2.0 actually useable. Not specifying a gl internal format in
Cogl so far has hidden the problem and let the implementation fall back
to RGB585 for example.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
Also be more strict about what we consider RGBA1010102 support. Before
GLES 3.0, using ReadPixels on a framebuffers with format RGB10_A2 was
not possible with type GL_UNSIGNED_INT_2_10_10_10_REV_EXT and thus our
code to read back pixels could fail.
Users of cogl should check those feature flags before using FP16 and
RGBA1010102 pixel formats via CoglFeatureIDs:
* COGL_FEATURE_ID_TEXTURE_RGBA1010102
* COGL_FEATURE_ID_TEXTURE_HALF_FLOAT
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3429>
If the EGL_KHR_no_config_context extension is supported, use it to
choose a format per onscreen which is compatible with the scanout CRTC
and the GL rendering API used.
Suggested by Jonas Ådahl.
v2:
* Drop code which checked for GLES3 renderability. Makes no sense for
various reasons, in particular that EGLconfigs are about EGLSurfaces,
whereas secondary GPU contexts use an FBO for blitting.
* Use error parameter directly for meta_renderer_native_choose_gbm_format
call (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
If the EGL_KHR_no_config_context extension is supported, pass
EGL_NO_CONFIG_KHR to eglCreateContext. This will allow binding the
context to surfaces created with different configs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
Scoped traces are less error prone, and they can still be ended
prematurely if needed (this commit makes that work). The only case this
doesn't support is starting a trace inside a scope but ending outside,
but this is pretty unusual, plus we have anchored traces for a limited
variation of that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3396>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
Make CoglBuffer an abstract class and inherit the various Cogl*Buffer types from it.
As none of the subclasses is overriding the vtable functions, they were not turned into
vfuncs but plain function pointers in CoglBuffer.
We still use _cogl_buffer_initialize until we port the various params into actual construct-only
properties, similar to the previous commit for CoglTexture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
These were leftovers from times when GL(ES) 1.x was still supported.
As we require HAVE_COGL_GL and/or HAVE_COGL_GLES2 to be defined, all
cases for checking both are now redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3338>
These functions ends-up calling gdk-pixbuf for loading textures/bitmaps
from a file and they don't seem to be used anywhere.
These changes are only useful with the following up commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3097>
