Do not include it at header side as it is not part of the installed headers.
Only keep it in cogl-gl-headers.h as it is a private header.
Add it to all the source files that depend on it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3593>
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>
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>
They are needed as "subformats" for higher bit YCbCr formats, such as
P010, and we don't plan to use or expose them otherwise. Thus don't
implement any conversion or packing features.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
So we can properly handle matching DRM and WL_SHM formats in a unified
manner.
Add extensive testing between these and existing pre-multiplied alpha
formats, i.e. all formats we support on Wayland.
Note that unfortunately for some format combinations the value in the
alpha channel is not cleared as expected, likely because of fast-paths
in Cogl. If both source and destination format is opaque, it always
works, however. This thereby includes all cases where they are the same.
Co-Authored-By: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
These match their alpha counterparts, apart from not setting the
alpha bit. This allows our internal mashinery to more easily
distinguish whether we need a slow alpha-pass during rendering or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1810>
These match their alpha counterparts, apart from not setting the
alpha bit. This allows our internal mashinery to more easily
distinguish whether we need a slow alpha-pass during rendering or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1810>
In order to support the DRM formats DRM_FORMAT_ABGR16161616F and
friends, as well as the wl_shm formats WL_SHM_FORMAT_ABGR16161616F and
friends, cogl needs to have knowledge about said formats too.
We don't have a software implementation of the half point data types
however, so the pack/unpack methods remain unimplemented. We don't need
them for now, so it's not crucial that we add them.
For the GLES2 driver, currently only two formats are supported, and
since we don't currently have pack/unpack implementations, the other
formats will for now remain unsupported, until we have a half float
implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/804
Just like libmutter-clutter, and libmutter, mark exported symbols with
an COGL_EXPORT macro. This removes the .map and .map.in files previously
used, containing a list of semi private symbols. This symbol was out of
date, i.e. pointed to non-existing symbols, and was also replaced with
COGL_EXPORT macros.
unit_test_* symbols are exported by the help of the unit test defining
macro. test_* symbols are no longer supported as it proved unnecessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
As we will start adding support for more pixel formats, we will need to
define a notion of planes. This commit doesn't make any functional
change, but starts adding the idea of pixel formats and how they (at
this point only theoretically) can have multple planes.
Since a lot of code in Mutter assumes we only get to deal with single
plane pixel formats, this commit also adds assertions and if-checks to
make sure we don't accidentally try something that doesn't make sense.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/858
By providing an (internal) table to map `CoglPixelFormat`s to their
respective properties we will be able to get rid of the unusual enum
values in the future. This is something we will need once we want to
have support for more pixel formats (such as YUV-based formats).
As an extra feature, we provide a `to_string()` method, which is quite
useful for debugging purposes (rather than deciphering enum values).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/524
We're going to add some features and extra code to CoglPixelFormat, so
it's much nicer to have it in once place. Notice also that it doesn't
make sense that e.g. `_cogl_pixel_format_get_bytes_per_pixel()` were in
a private header, since they were being exported anyway.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/524
