_cogl_shader_set_source_with_boilerplate and _cogl_shader_compile_real
have enough GL assumptions that it makes sense to push them into the
backend. Taken together their only callers are under driver/gl, so.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1194
This had been an entirely-too-GL-aware collection of renderer queries,
mostly to work around driver bugs and handle software drivers
intelligently. The driver workarounds have been removed (fix your
driver, and if you can't because it's closed-source, fix that first),
and we now delegate the am-i-software-or-not logic to the backend, so
this can all go
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1194
We delegate the answer through CoglDriverVtable::is_hardware_accelerated
since this is properly a property of the renderer, and not something the
cogl core should know about. The answer given for the nop driver is
admittedly arbitrary, yes it's infinitely fast but no there's not any
"hardware" making it so.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1194
If a test is not expected to succeed, then running it could be considered
to be a waste of resources, particularly if the failure might manifest
as an indefinite hang (see cogl!11), or if the test is likely to dump core
and trigger "expensive" crash-reporting mechanisms like systemd-coredump,
corekeeper, abrt or apport.
Skip the tests that are expected to fail. They can still be requested via
an environment variable, which can be set after fixing a bug to check which
tests are now passing.
Originally cogl!15, adapted for mutter's fork of cogl to use gboolean
instead of CoglBool.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1272
Signed-off-by: Simon McVittie <smcv@debian.org>
When r is 128 or more, running tests compiled with the undefined behaviour
sanitizer (ubsan) reports:
test-utils.c:312:45: runtime error: left shift of 128 by 24 places cannot be represented in type 'int'
which indeed it cannot. Force the type to be unsigned 32-bit so that we
get defined behaviour.
Similarly, in test-atlas-migration, the left-shifted guint8 is promoted
to int, which again does not have enough non-sign bits available to
left-shift a value >= 128 by 24 bits. Again, force the shift to be done
in unsigned 32-bit space.
This was originally cogl!22, but applies equally to mutter's fork of cogl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1271
Signed-off-by: Simon McVittie <smcv@debian.org>
According to the cogl_bitmap_new_for_data documentation, the data is not
copied, so the application must keep the buffer alive for the lifetime
of the CoglBitmap. Freeing it too early led to a use-after-free in the
cogl unit tests. With that fixed, the test passes, so remove the known
failure annotation.
This AddressSanitizer trace is from the original cogl, but the bug and
fix apply equally to mutter's fork of cogl:
==6223==ERROR: AddressSanitizer: heap-use-after-free on address 0x62100001a500 at pc 0x7f3e2d4e7f4e bp 0x7ffcd9c41f30 sp 0x7ffcd9c416e0
READ of size 4096 at 0x62100001a500 thread T0
#0 0x7f3e2d4e7f4d (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x96f4d)
#1 0x7f3e260c7f6b in util_copy_box ../src/gallium/auxiliary/util/u_surface.c:131
#2 0x7f3e268c6c10 in u_default_texture_subdata ../src/gallium/auxiliary/util/u_transfer.c:67
#3 0x7f3e26486459 in st_TexSubImage ../src/mesa/state_tracker/st_cb_texture.c:1480
#4 0x7f3e26487029 in st_TexImage ../src/mesa/state_tracker/st_cb_texture.c:1709
#5 0x7f3e26487029 in st_TexImage ../src/mesa/state_tracker/st_cb_texture.c:1691
#6 0x7f3e2644bdba in teximage ../src/mesa/main/teximage.c:3105
#7 0x7f3e2644bdba in teximage_err ../src/mesa/main/teximage.c:3132
#8 0x7f3e2644d84f in _mesa_TexImage2D ../src/mesa/main/teximage.c:3170
#9 0x7f3e2cd1f7df in _cogl_texture_driver_upload_to_gl driver/gl/gl/cogl-texture-driver-gl.c:347
#10 0x7f3e2ccd441b in allocate_from_bitmap driver/gl/cogl-texture-2d-gl.c:255
#11 0x7f3e2ccd441b in _cogl_texture_2d_gl_allocate driver/gl/cogl-texture-2d-gl.c:462
#12 0x7f3e2ce3a6c0 in cogl_texture_allocate cogl/cogl-texture.c:1398
#13 0x7f3e2ce3e116 in _cogl_texture_pre_paint cogl/cogl-texture.c:359
#14 0x7f3e2cdee177 in _cogl_pipeline_layer_pre_paint cogl/cogl-pipeline-layer.c:864
#15 0x7f3e2cd574af in _cogl_rectangles_validate_layer_cb cogl/cogl-primitives.c:542
#16 0x7f3e2cdd742f in cogl_pipeline_foreach_layer cogl/cogl-pipeline.c:735
#17 0x7f3e2cd5c8b0 in _cogl_framebuffer_draw_multitextured_rectangles cogl/cogl-primitives.c:658
#18 0x7f3e2cd60152 in cogl_rectangle cogl/cogl-primitives.c:858
#19 0x5570a71ed6a0 in check_texture tests/conform/test-premult.c:103
#20 0x5570a71ed946 in test_premult tests/conform/test-premult.c:159
#21 0x5570a71df0d6 in main tests/conform/test-conform-main.c:58
#22 0x7f3e2bcd809a in __libc_start_main ../csu/libc-start.c:308
#23 0x5570a71e0869 in _start (/home/smcv/src/debian/cogl/tests/conform/.libs/test-conformance+0x33869)
0x62100001a500 is located 0 bytes inside of 4096-byte region [0x62100001a500,0x62100001b500)
freed by thread T0 here:
#0 0x7f3e2d5581d7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x1071d7)
#1 0x5570a71ed58b in make_texture tests/conform/test-premult.c:69
previously allocated by thread T0 here:
#0 0x7f3e2d558588 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107588)
#1 0x7f3e2d384500 in g_malloc ../../../glib/gmem.c:99
This was originally cogl!12.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1274
Signed-off-by: Simon McVittie <smcv@debian.org>
Make it possible to cause the next frame to scan out directly from the
passed CoglScannout. This makes it possible to completely bypass
compositing for the following frame.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Instead of always swapping buffers and flipping the back buffer, make it
possible to scan out a provided buffer directly without swapping any EGL
buffers.
A buffer is passed as an object implementing the empty CoglScanout
interface. It is only possible to do this in the native backend; and the
interface is implemented by MetaDrmBufferGbm. When directly scanned out,
instead of calling gbm_surface_lock_front_buffer() to get the gbm_bo and
fbid, get it directly from the MetaDrmBufferGbm, and use that to create
the page flip KMS update.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
It isn't immediately obvious that this is impossible, because there's some
"action at a distance" going on with framebuffers that have their size
set lazily, after their textures get allocated; so let's make this a
critical warning rather than crashing.
In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.
Workaround for <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538>.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1172
Signed-off-by: Simon McVittie <smcv@debian.org>
A texture with no pixels isn't a useful thing to have, and breaks
assumptions elsewhere. For example, CoglFramebuffer assumes that after
a texture has been allocated, it will have width and height both greater
than 0.
In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.
Workaround for <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538>.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1172
Signed-off-by: Simon McVittie <smcv@debian.org>
cogl_object_[get|set]_value_object() are annotated as [get|set]-value-func
for objects and primitives, so they must be visible for any derived types
to be usable from introspection.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1146
In commit d846fabda we moved to using the override color alpha, however
it was missed that the actor opacity is transferred to the PangoRenderer
through the default color alpha, and the reason it was used there.
We actually want to factor in both alpha values, in order to respect
both foreground color alpha and actor opacity. This is done on the
unpremultiplied color, so we just need to change the alpha value.
Fixes effects on text actors that involve actor opacity.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1158
pango_renderer_get_alpha() returns 0 to indicate that the alpha value
should be inherited from the environment, but we are passing it on
(and therefore making the text fully translucent).
Instead, make the text fully opaque as expected.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1156
Cogl shares some GL functions between the GLES and the big
GL drivers. Namely, it shares _cogl_driver_gl_context_init
and _cogl_driver_gl_context_deinit between these two drivers.
The plot twist is: even though these functions are shared and
their prototypes are in cogl-util-gl-private.h, they're actually
implemented inside cogl-driver-gl.c, which is strictly only
about the big GL driver.
This is problematic when building Mutter on ARM v7, where we
need to disable OpenGL, but keep GLES enabled.
Fix this by moving the shared GL functions to a shared GL file.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1151
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
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
We need the stencil buffer to consist of binary values of 0 and 1
because we're doing additions and subtractions on the buffer, so even
though this is the default, explicitely set the stencil mask to 0x1.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1096
When using a region clip and something has a rectangle clip pushed, a
special drawing method for ClutterTexts (emit_vertex_buffer_geometry()
in cogl-pango-display-list.c) starts to fail and clipping issues with
long texts (because emit_vertex_buffer_geometry() is only used for texts
longer than 25 characters) start to appear. This specifically happened
in Looking Glass, where the StViewport of the ScrollView sets a
rectangle clips and the texts are usually longer than 25 characters.
This is caused by the changing of the perspective and modelview matrix
when drawing to the stencil buffer and started happening when
region-clipping was introduced with commit 8598b654. Even though the
changing of the matrices was done before that, too, the issue probably
didn't happen because `rect->can_be_scissor` was TRUE and no stencil
buffer clipping was used at all.
To fix this, temporarily save the old matrices, then set the new ones
and restore the old ones when we're done drawing to the stencil buffer.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2246https://gitlab.gnome.org/GNOME/mutter/merge_requests/1096
This is a winsys-specific API that allows exporting a DMA buffer fd.
The CoglDmaBufHandle structure allows passing the ownership of the
DMA buffer to whoever is using it, so the winsys doesn't need to
manually track it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
In future patches, we'll create additional CoglFramebuffers that
will be shared via DMA-Buf with PipeWire. When recording frames,
we'll blit the current onscreen framebuffer into the shared one.
However, that presents a problem: cogl_framebuffer_blit() mimics
glBlitFramebuffer() semantics, and doesn't do an implicit flush
of the GPU command stream. As a consequence, clients may receive
unblitted or incomplete framebuffers.
We could use cogl_framebuffer_finish() to ensure the commands were
submitted to the GPU, but it is too harsh -- it blocks the CPU
completely until the commands are finished!
Add cogl_framebuffer_flush(), which ensures the command stream is
submitted to the GPU without blocking the CPU. Even though we don't
use the framebuffer specifically, it may be useful in the future
for e.g. a potential Vulkan backend to have access to the framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
Just pass it in to the vertex shader like in GLES, it's one less thing
to vary between drivers. mutter is, shall we say, not a heavy user of
point primitives, so any performance impact (it might be measurable, who
knows) is not an issue. Again, the feature flag remains to be cleaned up
in a future commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/995
We're always running through the GLSL pipeline so the fixed-function
alpha test is never invoked. This change does not yet remove the
alpha-test feture bit from the context because this bit of uniform
handling is going to be simplified in a future commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/995
At this point only the gl driver is at all aware of the difference
between core and compat contexts. COGL_PRIVATE_FEATURE_GL_FIXED is also
now quite misnamed, since we're using the GLSL pipeline even for pre-GL3
contexts. Remove the private feature and handle the few remaining
differences by checking the driver class inside the gl driver.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/973
There's quite a bit of CoglContext that properly belongs to the driver.
Add some hooks to allow the context to create/destroy such state. We
don't have driver-private storage in the CoglContext yet, though we
probably should.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/973
This means CoglContext is now also introspected, although its
constructor and some getters are skipped to avoid having to expose even
more types. This makes it possible to create pipelines using Javascript.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
They have been deprecated for a long time, and all their uses in clutter
and mutter has been removed. This also removes some no longer needed
legacy state tracking, as they were only ever excercised in certain
circumstances when there was sources (pipelines or materials) on the now
removed source stack.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
This means cogl_set_source_color*() that switches to the opaque or
blending pipeline, or cogl_source_set_texture() which switches to the
texture pipeline.
Left is the opaque pipeline, as it is still used to compare other
pipelines to check whether they are opaque or not, and as the default
pipeline still pushed to the source stack during initialization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Change the warp modes test to sanity check CoglPrimitive based polygon
drawing instead of cogl_polygon(). This removes some checks, as
cogl_polygon() has explicitly documented special behaviour for automatic
wrap modes, which CoglPrimitive does not.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
The function create_texture() in test-wrap-modes.c takes a
TestUtilsTextureFlags. However a CoglTextureFlags is passed instead
in two calls. As the enums are identical this patch changes it to
use the TestUtils type.
The enum definitions:
typedef enum
{
COGL_TEXTURE_NONE = 0,
COGL_TEXTURE_NO_AUTO_MIPMAP = 1 << 0,
COGL_TEXTURE_NO_SLICING = 1 << 1,
COGL_TEXTURE_NO_ATLAS = 1 << 2
} CoglTextureFlags;
typedef enum
{
TEST_UTILS_TEXTURE_NONE = 0,
TEST_UTILS_TEXTURE_NO_AUTO_MIPMAP = 1 << 0,
TEST_UTILS_TEXTURE_NO_SLICING = 1 << 1,
TEST_UTILS_TEXTURE_NO_ATLAS = 1 << 2
} TestUtilsTextureFlags;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/938
In _cogl_offscreen_gl_allocate we only want to perform certain actions if
COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL is not set in create_flags.
We perfrom this check with:
if (!offscreen->create_flags & COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL)
which is not correct as we negate the create_flags before the bitwise &.
It happens to work as intended though, as CoglOffscreenFlags only has one
element, and that element has the value 1. If the flag is not set then the
nagation of create_flags is true and the bitwise and with the element value
is true as well.
If any flag is set then the negation will give 0 and the bitwise & will be
false.
So while it works correctly it is fragile as either additional flags or a
change in the enum element value will break this check. This patch makes
things a bit more safe by adding parentheses to let the bitwise & happen
before the negation.
Definition of the enum:
typedef enum
{
COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL = 1
} CoglOffscreenFlags;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/938
cogl_pipeline_get_front_face_winding() is supposed to return a CoglWinding. It
takes a CoglPipeline as argument and does the following input validation:
g_return_val_if_fail (cogl_is_pipeline (pipeline),
COGL_PIPELINE_CULL_FACE_MODE_NONE);
The returned COGL_PIPELINE_CULL_FACE_MODE_NONE is not a winding.
The function was added with this check 8 years ago in
5369b3c601
I do not see any of the two options in the CoglWinding as particularly good
choice for a return value on bad input, but let's go with
COGL_WINDING_CLOCKWISE as that is equivalent with the behavior for all
these years.
Definitions of the two enums:
typedef enum
{
COGL_WINDING_CLOCKWISE,
COGL_WINDING_COUNTER_CLOCKWISE
} CoglWinding;
typedef enum
{
COGL_PIPELINE_CULL_FACE_MODE_NONE,
COGL_PIPELINE_CULL_FACE_MODE_FRONT,
COGL_PIPELINE_CULL_FACE_MODE_BACK,
COGL_PIPELINE_CULL_FACE_MODE_BOTH
} CoglPipelineCullFaceMode;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/934
As noted in <cogl-texture-2d-gl.h> (now also removed), this is for
allowing external GL callers to promote one of their textures to a
CoglTexture. We aren't doing that and don't want to start.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/883
Unknown since when, we started deferring the eglMakeCurrent for the
current framebuffer till we started painting on it, which means we
are preparing for rendering a view without guarantees that the
framebuffer we will paint to is the current drawing surface for the
EGL context.
A fairly common case where that assumption will break is multimonitor
set ups, in this case we will be preparing to paint to a view while
the current draw surface is that of the previously rendered view's.
Mesa will in this case return EGL_BAD_SURFACE when querying the buffer
age, since the surface is not yet the current draw surface. This
makes us give up on buffer age checks, and paint the whole view. Since
the problem repeats when painting the next view, we are effectively
doing full-screen redraws on all monitors.
Since cogl usually works implicitly, and querying the buffer age is
meaningless if you're not meant to paint on a surface, make the surface
the current draw surface implicitly before querying the buffer age.
This brings us glorious partial invalidations back when several views
had to be repainted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/906
In order to avoid log spamming, just warn once it starts to happen, not
on every frame for every onscreen. Just knowing that this is happening
is a hint that something's going wrong.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/906
Say you're using intel gen3, you poor soul. Your big-GL maxes out at 1.5
unless you use dirty tricks, but you do have GLES2. We try to fall back
to GLES in this case, but we only ever say eglBindAPI(EGL_OPENGL_API).
So when we go to do CreateContext, even though we think we've requested
GLES 2.0, the driver will compare that "2.0" against the maximum big-GL
version, and things will fail.
Fix this by binding EGL_OPENGL_ES_API before trying a GLES context.
https://gitlab.gnome.org/GNOME/mutter/issues/635
In find_onscreen_for_xid() we want to loop over the framebuffers
and skip any that is not onscreen.
The code today does this by negating the framebuffer type variable
and skipping if that equals COGL_FRAMEBUFFER_TYPE_ONSCREEN. This
actually works as the enum used will function as a boolean:
typedef enum _CoglFramebufferType {
COGL_FRAMEBUFFER_TYPE_ONSCREEN,
COGL_FRAMEBUFFER_TYPE_OFFSCREEN
} CoglFramebufferType;
But it is a bit weird logic and fragile if more types are added.
(not that I can think of any different type...)
To simplify this, and to silence a warning in clang this patch just
changes it to a != test.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/905
There are still environment variables for these controls, but having
them in a config file doesn't really make sense for mutter. Even if it
did we probably don't want to be parsing the same file as some
standalone version of cogl.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/902
This is a _little_ strange, as we still fill in the vtable slot for
glRenderbufferStorageMultisampleIMG, and can in principle still call it.
But that feature was weird to begin with as we were only checking for
that function in big-GL contexts despite that its extension is for GLES.
I'll leave cleaning that up to a future pass.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/866
This was only promoted to core in 3.0, but Mesa's supported it
unconditionally since around 7.0 even in 2.1 contexts, so this is not a
particularly onerous requirement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/866
Midscene tracking was used at a time that some Cogl users
could call random OpenGL API without going through Cogl.
That is not allowed anymore, and certainly not done by
Mutter and GNOME Shell.
Remove midscene tracking from CoglFramebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
CoglJournal tracks a few OpenGL states so that they can
be batch-applied if necessary. It also has a nice property
of allowing purely CPU-based glReadPixels() when the scene
is composed of simple rectangles.
However, the current journal implementation leaves various
other GL states out, such as dithering and the viewport.
In Clutter, that causes the journal to be flushed when
picking, touching the GPU when we didn't really need to.
Track the viewport of the framebuffer in the journal so that
we can avoid flushing the journal so often.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
CoglFramebuffer checks the passed buffer bits in order to
detect when the fast path (that uses the journal) should
be used.
However, it also modifies one of the buffer bits that is
checked for the fast path, meaning we never actually hit
the fast path on cogl_framebuffer_cleaf4f().
Check the depth and color buffer bits before modifying them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
This is an extremely straightforward and minimalistic port of
CoglVector APIs to the corresponding Graphene APIs.
Make ClutterPlane use graphene_vec3_t internally too, for the
simplest purpose of keeping the patch focused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
As the first step into removing Cogl types that are covered by
Graphene, remove CoglEuler and replace it by graphene_euler_t.
This is a mostly straightforward replacement, except that the
naming conventions changed a bit. Cogl uses "heading" for the
Y axis, "pitch" for the X axis, and "roll" for the Z axis, and
graphene uses the axis themselves. That means the 1st and 2nd
arguments need to be swapped.
Also adapt the matrix stack to store a graphene_euler_t in the
rotation node -- that simplifies the code a bit as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Graphene is a small library with data types and APIs
specially crafted to computer graphics. It contains
performant implementations of matrices, vectors, points
and rotation tools. It is performance because, among
other reasons, it uses vectorized processor commands
to compute various operations.
Add Graphene dependency to Mutter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
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
This is for all intents and purposes the same as
`cogl_object_ref/unref`, but still refers to handles rather than
objects (while we're trying to get rid of the former) so it's a bit of
unnecessary redundant API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/451
It wasn't necessary (see other instances of -DG_LOG_DOMAIN) and somewhere
along the line it was getting turned into forward slashes becoming a syntax
error:
```
/usr/include/glib-2.0/gobject/gobject.h:767: syntax error, unexpected '/' in
...
g_assertion_message (/"CoglPango/",
```
https://gitlab.gnome.org/GNOME/mutter/merge_requests/841
Threaded swap wait was added for using together with the Nvidia GLX
driver due to the lack of anything equivalent to the INTEL_swap_event
GLX extension. The purpose was to avoid inhibiting the invocation of
idle callbacks when constantly rendering, as the combination of
throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
source having higher priority than the default idle callback sources
meant they would never be invoked.
This was solved in gbz#779039 by introducing a thread that took care of
the vsync waiting, pushing frame completion events to the main thread
meaning the main thread could go idle while waiting to draw the next
frame instead of blocking on glxSwapBuffers().
As of https://gitlab.gnome.org/GNOME/mutter/merge_requests/363, the
main thread will instead use prediction to estimate when the next frame
should be drawn. A side effect of this is that even without
INTEL_swap_event, we would not block as much, or at all, on
glxSwapBuffers(), as at the time it is called, we have likely already
hit the vblank, or will hit it soon.
After having introduced the swap waiting thread, it was observed that
the Nvidia driver used a considerable amount of CPU waiting for the
vblank, effectively wasting CPU time. The need to call glFinish() was
also problematic as it would wait for the frame to finish, before
continuing. Due to this, remove the threaded swap wait, and rely only on
the frame clock not scheduling frames too early.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
Related: https://gitlab.gnome.org/GNOME/mutter/issues/700
[jadahl: Rewrote commit message]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/602
This was introduced in:
commit 010d16f647
Author: Robert Bragg <robert@linux.intel.com>
Date: Tue Mar 6 03:21:30 2012 +0000
Adds initial GLES2 integration support
This makes it possible to integrate existing GLES2 code with
applications using Cogl as the rendering api.
That's maybe a reasonable thing for a standalone cogl to want, but our
cogl has only one consumer. So if we want additional rendering out of
our cogl layer, it makes more sense to just add that to cogl rather than
support clutter or mutter or the javascript bindings creating their own
GLES contexts.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/500
The function will be used in copying from a primary GPU framebuffer to a
secondary GPU framebuffer using the primary GPU specifically when the
secondary GPU is not render-capable.
To allow falling back in case glBlitFramebuffer cannot be used, add boolean
return value, and GError argument for debugging purposes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Depends on "cogl: Replace ANGLE with GLES3 and NV framebuffer_blit"
Allow blitting between onscreen and offscreen framebuffers by doing the y-flip
as necessary. This was not possible with ANGLE, but now with ANGLE gone,
glBlitFramebuffer supports flipping the copied image.
This will be useful in follow-up work to copy from onscreen primary GPU
framebuffer to an offscreen secondary GPU framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Depends on: "cogl: Replace ANGLE with GLES3 and NV framebuffer_blit"
As a possible ANGLE implementation is not longer limiting the pixel format
matching, lift the requirement of having the same pixel format.
We still cannot do a premult <-> non-premult conversion during a blit, so guard
against that.
This will be useful in follow-up work to copy from onscreen primary GPU
framebuffer to an offscreen secondary GPU framebuffer if the formats do not
match exactly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
ANGLE extensions are only provided by Google's Almost Native Graphics Layer
Engine (ANGLE) implementation. Therefore they do not seem too useful for
Mutter.
The reason to drop GL_ANGLE_framebuffer_blit support is that it has more
limitations compared to the glBlitFramebuffer in GL_EXT_framebuffer_blit,
GL_NV_framebuffer_bit, OpenGL 3.0 and OpenGL ES 3.0. Most importantly, the
ANGLE version cannot flip the image while copying, which limits
_cogl_blit_framebuffer to only off-screen <-> off-screen copies. Follow-up work
will need off-screen <-> on-screen copies.
Instead of adding yet more capability flags to Cogl, dropping ANGLE support
seems appropriate.
The NV extension is added to the list of glBlitFramebuffer providers because it
provides the same support as ANGLE and more.
Likewise OpenGL ES 3.0 is added to the list of glBlitFramebuffer providers
because e.g. Mesa GLES implementation usually provides it and that makes it
widely available, again surpassing the ANGLE supported features.
Follow-up patches will lift some of the Cogl assumptions of what
glBlitFramebuffer cannot do.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Public functions in C should be declared before they are defined, and
often compilers warn you if you haven't:
```
../cogl/cogl/cogl-trace.c:237:1: warning: no previous prototype for
‘cogl_set_tracing_enabled_on_thread_with_fd’ [-Wmissing-prototypes]
cogl_set_tracing_enabled_on_thread_with_fd (void *data,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../cogl/cogl/cogl-trace.c:245:1: warning: no previous prototype for
‘cogl_set_tracing_enabled_on_thread’ [-Wmissing-prototypes]
cogl_set_tracing_enabled_on_thread (void *data,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../cogl/cogl/cogl-trace.c:253:1: warning: no previous prototype for
‘cogl_set_tracing_disabled_on_thread’ [-Wmissing-prototypes]
cogl_set_tracing_disabled_on_thread (void *data)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
In this case the function declarations were not included because
`HAVE_TRACING` isn't defined. But we should still include `cogl-trace.h`
because it handles the case of `HAVE_TRACING` not being defined and
correctly still declares the functions defined in `cogl-trace.c`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/650
`cogl_util_memmem` was used as a wrapper in case `memmem` wasn't
defined, but since commit 46942c24 these are required. In case of
`memmem`, we didn't explicitly require this in the meson build files, so
add that as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/629
These are implemented in the Meta namespace these days, where we have
better abstractions for wayland-related types. They also weren't used
anymore, since we removed the unused ClutterWaylandSurface type in the
previous commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/624
The idea here is to be able to visualize and immediately
understand what is happening. Something like:
```
[ view1 ] [ view2 ]
[---- Layout ---][------ Paint ------][ Pick ]
[================== Update =====================]
```
But with colors. A few of the previous profiling data
sections were removed, since they didn't really add to
reading the graph.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
Add the ability to add tracing instrumentation to the code. When
enabled, trace entries will generate a file with timing information
that will be processable by sysprof for generating visualization of
traces over time.
While enabled by default at compile time, it is possible to disable the
expansion of the macros completely by passing --disable-tracing to
./configure.
Tracing is so far only actually done if actually enabled on explicitly
specified threads.
This will be used by Mutter passing the write end of a pipe, where the
read end is sent to Sysprof itself via the D-Bus method 'Capture()'.
By passing that, we have to detect EPIPE that is sent when Sysprof stops
recording. Fortunately, we already ignore the signal at meta_init(), so
no need to add a custom signal handler.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/197
Add debug flags based on meson's `debug` option instead of `buildtype`.
This allows custom build configurations to behave like a debug or release build.
Add `-fno-omit-frame-pointer` to Mutter/Cogl. Not to Clutter though, as that would
require more changes to how Clutter's gir is created
Remove `-DG_DISABLE_CAST_CHECKS` from Clutter in debug builds
Add `-DG_DISABLE_CHECKS`, `-DG_DISABLE_ASSERT` and `-DG_DISABLE_CAST_CHECKS` to all
non-debug builds but `plain`, which explicitly should not have any compile flags
Use `cc.get_supported_arguments`, so it becomes more obvious to the user which flags
are set during compilation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/497
When free'ing a pipeline we destroy the BigState first and then the fragment and
vertex snippets lists using the big state pointer which is now invalid.
This causes a crash when G_SLICE=always-malloc is set and using MALLOC_CHECK_.
So, invert the operations by free'ing the snippet lists first, and the big state
afterwards.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
XLib renderer saves its data as the object cogl user data, however this data
is free'd as part of the object destruction that happens before free'ing the
renderer in _cogl_renderer_free(), from where we're calling the renderer
disconnect vfunc.
Thus in _cogl_xlib_renderer_disconnect() we happen to get an invalid pointer to
CoglXlibRenderer and we try access to it in order to close the X11 display.
This causes all the cogl tests to crash when G_SLICE=always-malloc is set and
when using MALLOC_CHECK_.
Fix this using the renderer winsys custom data instead of using cogl object data
for storing the CoglXlibRenderer, and handling the destruction of it manually.
As bonus this also makes access to the renderer data faster.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
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
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
GList's used in legacy code were free'd using a g_list_foreach + g_list_free,
while we can just use g_list_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
Cogl unit tests are just functions inside normal code files that needs to be
dload'ed by the test binary.
So in case unit-tests are enabled, we need to export those symbols.
Since map file can't be overridden, use a configure_file to generate the map
file when tests are enabled, in order to export the needed symbols.
Then goes through the source files to look unit tests checking for their macro
definition and load them with the runner script.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
Use find-conform-unit-tests.sh to create a meson list of tests to run.
This allows to run each test as single test with meson and to remove the timeout
for all the tests.
Instead of changing 'run-tests.sh' to take test-names as arguments we can just
generate simple dummy test-files for each test, without having to change the
tooling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
We already effectively require GLSL, because there's no fixed-function
backend anymore. OpenGL 2.0 drivers don't really exist in the wild, so
just go ahead and require 2.1 or better. 2.1 implies GLSL 1.20 or
better, so simplify that as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/489
This is effectively a revert of:
commit 6cfc93f26f
Author: Robert Bragg <robert@linux.intel.com>
Date: Tue Oct 2 11:44:00 2012 +0100
clip-stack: workaround intel gen6 viewport clip bug
It's been over six years, if this bug is still present we should just
fix Mesa already.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/481
If a second `set_{sync,complete}_pending` was queued before the idle
handler had flushed the first then one of them would be forgotten.
It would stay queued forever and never emitted as a notification.
This could happen repeatedly causing a slow leak. But worse still,
`clutter-stage-cogl` would then have `pending_swaps` permanently stuck
above zero preventing the presentation timing logic from being used.
The problem is that a boolean can only count to one, but in some cases
(triple buffering, whether intentional or accidental #334) we need it to
count to two. So just change booleans to integers and count properly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/216
Meson 0.50.0 made passing an absolute path to install_headers()'
subdir keyword a fatal error. This means we have to track both
relative (to includedir) paths for header subdirs and absolute
paths for generated headers now :-(
https://gitlab.gnome.org/GNOME/mutter/merge_requests/492
As it was originally reported on
https://bugzilla.gnome.org/show_bug.cgi?id=779234#c0, the hottest path was
convert_ubyte() in mesa. Reverting this shows no trace of those hot paths,
nor any higher than usual CPU activity.
As the improvements at the time were real, I can only conclude that pixel
conversion was happening somewhere further the pipeline, and swizzling just
helped indirectly. That got eventually fixed, so swizzling just stayed to
cause grief. And lots it caused.
Time to bin this, it seems.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/486
This basically reverts commit 54735dec, which tried to avoid the
GLib-defined types in favor the standard C ones. One exception to this
is the bool type, for which the commit introduces a new type CoglBool.
Let's just get rid of this type in favor of having consistency with the
GLib types. Note by the way that neither CoglBool nor gboolean (which
has a size of `int`) are completely compatible with bool (size `char`).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
Until meson 0.50, setting the install parameter in 'configure_file' is ignored
if 'install_dir' is set. Then until mutter doesn't depend on such meson version
cogl_installed_tests_libexecdir should be empty unless have_installed_tests is
false, or this file will be installed anyway.
See https://github.com/mesonbuild/meson/issues/4160
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
pkg-config files for mutter are generated using *_pkg_deps as requires, but
programs linked with libmutter doesn't need most of these private dependencies
which are only needed for building and linking mutter and its subprojects.
So list packages needed only by mutter itself inside *_pkg_private_deps and
don't expose such packages to pkg-config, but only use them at build time.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Soname of the libraries should be the major version number, while the version
triplet is currently used:
objdump -p libmutter-4.so.0.0.0 | grep SONAME
SONAME libmutter-4.so.0.0.0
While is expected to be only libmutter-4.so.0
Fix all shared libraries by setting valid version and soversion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3955
Map files were using wrong syntax (missing final `;` or invalid chars).
Also, the map files were only monitored for rebuilding, but not really used by
ld, so pass the ldflags with version-script so that private symbols are really
hidden.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
In plenty of places a non-static function was defined but didn't have
the corresponding declaration. Fix this by adding them, or alternatively
making them static.
cogl-path uses types from glu.h, but to avoid a build dependency on glu,
it kept a minified copy of glu.h in tree. Drop this file and just use
the actual glu.h. To avoid linking to libGLU.so, just use the
includepath, instead of actually adding glu as a real dependency.
This means we can remove an includepath meant to make it possible to
include <GL/glu.h>.
gluTessCallback() expects an equivalent to a GFunc, but we pass
functions with arguments without casting. To get rid of warnings, cast
the callback function pointer to the expected type.
I saw Meson fade from the sky
On the wind I heard a sigh
As snowflakes cover fallen Makefiles
I will say this last goodbye
Meson is now coming
So ends Autotools days
Future is now coming
And we must away
Over Python and without Bashisms
Through lands where never Meson touched
By silver streams that run down to the Sea
Under parsers, beneath old legacy
Over snow one winter’s morn
I turned at last to paths that lead home
And though where the road then takes me
I cannot tell
We came all this way
But now comes the day
To bid you farewell
Many places I have been
Many sorrows I have seen
But I don’t regret
Nor will I forget
All Makefiles that took that road with me
I bid you all a very fond farewell.
If a library is provided in the positional arguments, then meson
defaults to installing the .pc file in a 'pkgconfig' subdirectory
in the library's install location. We want the files in the regular
$libdir/pkgconfig rather than $libdir/mutter-$api/pkgconfig, so
specify the location explicitly in the parameters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/382
Dependencies are added automatically, and we no longer get warnings
like:
clutter/clutter/meson.build:628: DEPRECATION: Library mutter-clutter-4
was passed to the "libraries" keyword argument of a previous call to
generate() method instead of first positional argument. Adding
mutter-clutter-4 to "Requires" field, but this is a deprecated behaviour
that will change in a future version of Meson. Please report the issue
if this warning cannot be avoided in your case.
While for normal textures, GL_TEXTURE_2D should be used, when it's an external
texture, binding it using GL_TEXTURE_2D results in an error.
Reading the specification for GL_TEXTURE_EXTERNAL_OES it is unclear whether
getting pixel data from a texture is possible, and tests show it doesn't result
in any data, but in case it would eventually start working, at least bind the
correct target for now.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
Don't just set the internal format to the dummy format "any", as that causes
code intended to be unreachable code to be reached. It's not possible to
actually know the internal format of an external texture, however, so it might
not actually correspond to the real format.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/362
This makes the build less verbose, as all .gir generation except for
clutters didn't pass --quiet to g-ir-scanner, making it output long
linking commands. Do this by adding a common introspection_args
variable.
While at it, put -U_GNU_SOURCE in there too, as it was always passed
everywhere as without it the scanner would log warnings.
This is the last remaining feature necessary to achieve
parity with the Autotools build.
A few changes were made to the install locations of the
tests, in order to better acomodate them in Meson:
* Tests are now installed under a versioned folder (e.g.
/usr/share/installed-tests/mutter-4)
* The mutter-cogl.test file is now generated from an .in
file, instead of a series of $(echo)s from within Makefile.
Notice that those tests need very controlled environments
to run correctly. Mutter installed tests, for example, will
failed when running under a regular session due to D-Bus
failing to acquire the ScreenCast and/or RemoteScreen names.
When running installed tests, the working directory for Cogl
tests is /usr/libexec/installed-tests/mutter-cogl-4/conform,
which isn't writable by normal users.
To avoid the adding stray hidden files to the current directory,
adapt the runner script to fallback to $(mktemp) - which is
available on all platform we care about - and avoid adding
hidden files everywhere.
Presumably glReadPixels itself can be more performant with pixel format
conversions than doing a fix-up conversion on the CPU afterwards. Hence,
pick required_format based on the destination rather than the source, so
that it has a better chance to avoid the fix-up conversion.
With CoglOnscreen objects, CoglFramebuffer::internal_format (the source
format) is also wrong. It is left to a default value and never set to
reflect the reality. In other words, read-pixels had an arbitrary
intermediate pixel format that was used in glReadPixels and then fix-up
conversion made it work for the destination.
The render buffers (GBM surface) are allocated as DRM_FORMAT_XRGB8888.
If the destination buffer is allocated as the same format, the Cogl
read-pixels first converts with glReadPixels XRGB -> ABGR because of the
above default format, and then the fix-up conversion does ABGR -> XRGB.
This case was observed with DisplayLink outputs, where the native
renderer must use the CPU copy path to fill the "secondary GPU"
framebuffers.
This patch stops using internal_format and uses the desired destination
format instead.
_cogl_framebuffer_gl_read_pixels_into_bitmap() will still use
internal_format to determine alpha premultiplication state and multiply
or un-multiply as needed. Luckily all the formats involved in the
DisplayLink use case are always _PRE and so is the default
internal_format too, so things work in practise.
Furthermore, the GL texture_swizzle extension can never apply to
glReadPixels. Not even with FBOs, as found in this discussion:
https://gitlab.gnome.org/GNOME/mutter/issues/72
Therefore the target_format argument is hardcoded to something that can
never match anything, which will prevent the swizzle from being assumed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/313
This function gets hit even today on relatively modern Intel systems (I
have a Haswell Desktop with Mesa 18.2.4) if the pixel format is right.
Presumably it makes things slower for no longer a reason.
According to cb146dc515, this
functionality was refactored into a workaround path in 2012. The commit
message mentions the problem existing before Mesa 8.0.2. The number
refers to https://bugs.freedesktop.org/show_bug.cgi?id=46631 .
The use case where I hit this is when improving support for DisplayLink
video outputs. These are used through a "secondary GPU", and since
DisplayLink does not have a GPU, Mutter uses the CPU copy path with Cogl
read-pixels[1]. If the DisplayLink framebuffer was allocated as
DRM_FORMAT_XRGB8888 (the only format it currently handles correctly),
mesa_46631_slow_read_pixels_workaround would get hit. The render buffer is
the same format as the framebuffer, yet doing the copy XRGB -> XRGB ends
up being slower than XRGB -> XBGR which makes no sense.
This patch is not sufficient to fix the XRGB -> XRGB copy performance,
but it is required.
This patch reverts CoglGpuInfoDriverBug into what it was before
cb146dc515.
[1] This is not actually true until
https://gitlab.gnome.org/GNOME/mutter/merge_requests/278 is
merged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/313
The depth buffer is marked as invalid when 1) the framebuffer is just created,
and 2) whenever GL_DEPTH_TEST is enabled on it. This will ensure the
framebuffers attached depth buffer (if any) is properly cleared before it's
actually used, while saving needless clears while depth testing is disabled
(the default).
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Since now we don't set the swap throttled value based
on sync-to-vblank, we can effectively remove it from
Cogl. Throttling swap buffers in Cogl is as much a
historical artifact as sync-to-vblank. Furthermore,
it doesn't make sense to disable it on a compositor,
which is the case with the embedded Cogl.
In addition to that, the winsys vfunc for updating
whenever swap throttling changes could also be removed,
since swap throttling is always enabled now.
Removing it means less code, less branches when running,
and one less config option to deal with.
This also removes the micro-perf test, since it doesn't
make sense for the case where Cogl is embedded into the
compositor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/191
This commit includes following fixes for a few shell scripts:
1. Follow the best practice of quoting variables everywhere unless they
are used in places where word-splitting and globbing can never happen.
2. Replace `command` with $(command) because the latter is easier to use
and read.
3. Don't use "$@" in places expecting a string because it is an array
of strings instead of a single string.
Bash is not always installed in /bin and we should not hardcode the path
of it in source code which is expected to be built on many operating
systems and distributions.
Since most scripts using #!/bin/bash here doesn't have any bashism,
they can be converted to #!/bin/sh instead of using /usr/bin/env trick.
This macro was introduced so as to be able to be built without GLib.
However, this feature was long ago removed, and in Mutter we depend on
it anyway, so let's get rid of it in favor of more consistency.
This is based on `g_clear_object`, so it will be a bit more consistent
to write (and prevents the headaches from accidentally forgetting a NULL
check).
If texture allocation fails (e.g. on an old GPU with size limit 2048)
then `cogl_texture_new_with_size` was trying to use the same CoglError
twice. The second time was after it had already been freed.
Bug reported and fix provided by Gert van de Kraats.
https://launchpad.net/bugs/1790525
This will allow CoglFramebuffer and its implementations to be exposed
to GJS and other language bindings. This is a necessary part of the
bigger work to make framebuffer management explicit.
CoglOffscreen is effectively a CoglFramebuffer, but it isn't being marked as
such by the GType machinery. This makes it impossible for introspection to
correctly set this class up.
Fix that by adding a COGL_GTYPE_IMPLEMENT_INTERFACE() code into the declaration
of CoglOffscreen. This does not have any functional changes though.
Meson uses the 'dependencies' field to determine and
parallelize build steps, but that isn't entirely true
with 'link_with'; this might cause a race condition
when generating header files while trying to build
them.
Fix that by only using 'dependencies' instead of 'link_with'.
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
Install include files in
$prefix/include/mutter-$apiversion/[clutter,cogl,...,meta]/, and
datafiles in /usr/share/mutter-$apiversion/.... We still would conflict
e.g. given that our gettext name is "mutter", and how keybindings are
installed, but it's a step in the right direction.
There are different unit-tests file generated containing lists of tests
the test-runner.sh should run. Running run-tests.sh read the unit-tests
in the current directory, which is inconvenient to do when using meson.
The docs previously suggested that `cogl_frame_info_get_frame_counter`
returned a timestamp of an unknown clock ID. That's not correct. The
cogl source code shows that it does and must use the same clock as
`cogl_get_clock_time`.
Related to https://gitlab.gnome.org/GNOME/mutter/issues/131
Before we just set it to "none", but this was not enough since various
calls will depend on not just the context being active, but the main
rendering surface.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/21
By the looks of it, commit 95e9fa10ef was taping over an Intel DRI bug
that would make it return post-swizzling pixel data on glReadPixels().
There's been reports over time of that commit resulting in wrong colors
on other drivers, and lately Mesa >17.3 started showing the same symptoms
on Intel.
But texture swizzling works by changing parameters before fragment shaders
and reading pixels from an already drawn FBO/texture doesn't involve those.
This should thus use pixel_format_to_gl_with_target(), which will result in
correctly requesting the same pixel format than the underlying texture,
while still considering it BGRA for the upper layers in the swizzling case.
https://gitlab.gnome.org/GNOME/mutter/issues/72Closes: #72
We just arbitrarily chose the first EGL config matching the passed
attributes, but we then assumed we always got GBM_FORMAT_XRGB8888. That
was not a correct assumption. Instead, make sure we always pick the
format we expect.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/2
On drivers that do not support glGetTexImage2D (i.e. on GLES),
cogl_texture_get_data() has a "feature" that allows it to download
texture data by rendering the texture on an intermediate framebuffer
object and then reading back the data from there. However, this
feature requires the user to have previously set an "active"
framebuffer object in the context, which makes this very tricky
because it is not clear to the developer that he needs to do that
in order for some code to work on GLES (of course it works on
desktop GL, so nobody notices...) and additionally the code actually
crashes if an active fbo is not set!
This patch basically removes this feature in order to prevent
the crash and is in line with how this code has evolved in cogl-2.0:
https://git.gnome.org/browse/cogl/commit/?id=6d6a277b8e9a63a8268046e5258877ba94a1da5bhttps://bugzilla.gnome.org/show_bug.cgi?id=789961
When creating a renderer with a custom winsys (which is always how
mutter uses cogl) make it possible to pass a user data with the winsys.
Still unused.
https://bugzilla.gnome.org/show_bug.cgi?id=785381
The GL_BGRA definition is not available for GLES2 contexts, which use
the EXT_texture_format_BGRA8888 instead, causing a build failure when
trying to use it in those contexts.
Fortunately, this hack is only relevant for GL, so let's guard it to
prevent the failure in GLES2, where that extension is used instead.
https://bugzilla.gnome.org/show_bug.cgi?id=786568
Those are cached and reused across runs, which doesn't qualify to mesa
as "static" indeed. Properly marking those as dynamic is more true, and
brings in slight performance benefits just by avoiding the resulting
(and later silenced) mesa warning.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
Fixes cogl_texture_get_data() resorting to the wrong conversions when
extracting the texture data. This notably resulted in RGB/RGBA buffers
copied as-is into BGRA buffers, for instance for the fullscreen animation,
or single-window screenshots of such buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
The ARB_robustness extension defined the following tokens as
returned by GetGraphicsResetStatusARB (see spec at [1]):
GUILTY_CONTEXT_RESET_ARB 0x8253
INNOCENT_CONTEXT_RESET_ARB 0x8254
UNKNOWN_CONTEXT_RESET_ARB 0x8255
These tokens might not be defined in some GL implementations,
such as Mesa 13's implementation of GLES 2.0, so we need to
define them ourselves not to break those builds.
[1] https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_robustness.txthttps://bugzilla.gnome.org/show_bug.cgi?id=781398
We already do have a texture with an internal format in these paths,
so we should check the required format according to it.
This fixes CoglAtlasTexture (and CoglPangoRenderer indirectly), as
it forces a RGBA format on its texture, but pixel_format_to_gl()
anyway assumed swizzling is performed on the texture, while it is
not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
This is used by the GL driver in order to determine whether swizzling
actually applies given the bitmap and target texture internal format.
If both agree that they store BGRA, then swizzling may apply.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
If the GL implementation/hw supports the GL_*_texture_swizzle extension,
pretend that BGRA textures shall contain RGBA data, and let the flipping
happen when the texture will be used in the rendering pipeline.
This avoids rather expensive format conversions when forcing BGRA buffers
into RGBA textures, which happens rather often with WL_SHM_FORMAT_ARGB8888
buffers (like gtk+ uses) in little-endian machines.
In intel/mesa/wayland, the performance improvement is rather noticeable,
CPU% as seen by top decreases from 45-50% to 25-30% when running
gtk+/tests/scrolling-performance with a cairo renderer.
https://bugzilla.gnome.org/show_bug.cgi?id=779234
Because the threaded-swap-wait functionality requires XInitThreads(),
and because it isn't clear that it is a win for all applications,
add a API function to conditionally enable it.
Fix the cogl-crate example not to just have a hard-coded dependency
on libX11.
https://bugzilla.gnome.org/show_bug.cgi?id=779039
It's a good guess that the buffer swap will occur at the next vblank,
so use glXWaitVideoSync in a separate thread to deliver a sync event
rather than just letting the client block when frame drawing, which
can signficantly change app logic as compared to the INTEL_swap_event
case.
https://bugzilla.gnome.org/show_bug.cgi?id=779039
When we don't have GLX_OML_sync_control, we still can set the
frame presentation time, but we always use the system monotonic time,
so return that from get_clock_time().
https://bugzilla.gnome.org/show_bug.cgi?id=779039
As previously commented in the code, SGI_video_sync is per-display, rather
than per-renderer. The is_direct flag for the renderer was tested before
it was initialized (per-display) and that resulted in SGI_video_sync
never being used.
https://bugzilla.gnome.org/show_bug.cgi?id=779039
In order to minimize the amount of breakage, while at the same time
making it easier to make backward incompatible changes needed to
continue turning libmutter into a capable Wayland compositor, make the
libmutter and friends (libmutter-clutter, libmutter-cogl*) parallel
installable by adding a version number to the name. This changes
various filenames, for example what previously was libmutter.so is now
libmutter-0.so (assuming the version for now is 0), and
libmutter-clutter-1.0.so is now libmutter-clutter-0.so. The pkg-config
filenames and GObject introspection has been renamed to reflect this as
well.
This enables a downstream compositor rely on a specific version of the
libmutter API, while gracefully handling API/ABI changes by having to
update to the new version at their own pace.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
Different libEGL will do different things for eglGetDisplay since it has
to guess what kind of display it's been handed. Better to just use the
API that makes it explicit.
Signed-off-by: Adam Jackson <ajax@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772422
We need a GLES2 extension macro in cogl-texture-2d-gl.c, but we can't
include GLES2/gl2ext.h because it will conflict with things in
GL/glext.h. We can't rely on cogl including anything for us since it'd
only include GLES2/gl2ext.h if OpenGL support was explicitly disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=774891
EGLDevice requires a define from GLES2, even when GL is used instead.
As type definitions may conflict between the two, we shouldn't include
both at the same time. Instead, provide the missing define explicitly
when not using GLES2.
https://bugzilla.gnome.org/show_bug.cgi?id=774891
Add API to enable the caller to have a custom method for allocating an
external texture. This will enable the possibility for mutter to
generate a texture from for example an EGLStream without having to add
support for that in Cogl.
https://bugzilla.gnome.org/show_bug.cgi?id=773629
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
The WL_bind_wayland_display spec says that EGL images should be created
using EGL_WAYLAND_BUFFER_WL as the target and a NULL context. Mesa
seems to be lenient and accept any context, however some other stacks
aren't so forgiving and fail if anything apart from EGL_NO_CONTEXT is
used.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769731
Mutter (and libmutter users) are the only users of this version of
cogl, and will more or less only use the cogl-1.0, cogl-2.0 and cogl
experimental API variants, and having the possibility of having
different API versions of the same API depending on what file includes
it is error prone and confusing. Lets just remove the possibility of
having different versions of the same API.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
We bypass our build configuration to fetch API from a version which
isn't the one we actually use. Stop bypassing and just admit that the
1.0 API is still there, but still deprecated.
https://bugzilla.gnome.org/show_bug.cgi?id=768977
CoglFrameInfo is a frame info container associated with a single
onscreen framebuffer. The clutter stage will eventually support drawing
a stage frame with multiple onscreen framebuffers, thus needs its own
frame info container.
This patch introduces a new stage signal 'presented' and a accompaning
ClutterFrameInfo and adapts the stage windows and past onscreen frame
callbacks users to use the signal and new info container.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Move the KMS interaction from cogl into mutter, where most of the other
KMS interaction already takes place. This also removes dead code which
were only excercised when non-mutter callers used the cogl KMS backend.
The cogl KMS API was updated to pass via MetaRendererNative instead of
via the different cogl objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
In cogl use cogl-config.h and in clutter use clutter-build-config.h. We
can't use clutter-config.h in clutter because its already used and
installed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
If you include a file that might define __INSIDE_COGL_H__, don't
undefine it if it wasn't defined in that file. This makes it possible
to include for example cogl-gles2.h from some other file which defines
__INSIDE_COGL_H__.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
When using a context with robustness, glGetError() may return
GL_CONTEXT_LOST at any time and this error doesn't get cleared until
the application calls glGetGraphicsResetStatus() . This means that our
error checking can't call glGetError() in a loop without checking for
that return value and returning in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
commit 188752158 changed cogl to stop needlessly creating its own
monitor output configuration when mutter would just soon overwrite
it anyway.
Unfortunately, that commit is causing a crash in some cases because
cogl will now create and later draw to a 0x0 egl surface until mutter
sets the monitor layout.
This commit changes cogl to avoid creating and using a surface, before
it knows how big of a surface to create.
https://bugzilla.gnome.org/show_bug.cgi?id=758073
If we get EACCES from drmPageFlip we're not going to get
a flip event and shouldn't wait for one.
This commit changes the EACCES path to silently ignore the
failed flip request and just clean up the fb.
https://bugzilla.gnome.org/show_bug.cgi?id=756926
ES3 provides glMapBufferRange as core, with the added bonus that it also
supports read mappings. Use this where possible.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728355
GLES2 does not support passing READ to glMapBuffer; attempting to call
cogl_buffer_map for read on ES2 will bring it down with an assert. Make
sure COGL_DEBUG=journal doesn't do this when it's not possible.
Signed-off-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728355
On Wayland deinit() of an onscreen buffer is going to destroy the
associated native window of an EGLSurface. So we should destroy the
EGLSurface as well otherwise we might end up confusing the GL driver.
We also currently guard against setting a EGL_NO_SURFACE as current
EGLSurface, but this shouldn't be a problem if we have a surfaceless
context. So we allow surface destruction under that condition.
https://bugzilla.gnome.org/show_bug.cgi?id=754667
If the user switches VTs in the middle of a page flip, the
page flip operation may fail with EACCES. page flipping will
work next time the VT becomes active, so we shouldn't disable
page flipping in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
If cogl fails to open the drm device, initialize gbm, or open the
egl display, then it closes the drm fd, uninitializes gbm, closes the
display and then calls _cogl_winsys_renderer_disconnect which does
most of those things again, on the, now deinitialized, members.
This commit removes the explicit failure handling in renderer_connect and
defers cleanup to disconnect.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
gbm confusingly has two different format types, and cogl
is using the wrong one in some of its calls to gbm_surface_create
This commit fixes the calls that are wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=754540
glGetIntegerv (GL_DEPTH_BITS, ...) and friends are deprecated in GL3; we
have to use glGetFramebufferAttachmentParameteriv() instead, like we do
for offscreen framebuffers.
Based on a patch by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=753295
We want to be able to retrieve the XVisualInfo used when creating the
GL context under GLX and EGL-X11, so that we can use the visual before
we have an onscreen frame buffer.
Initialize variables; GCC does not always catch all cases where the
variables are used after being initialized, especially when it comes to
out parameters.
Some drivers ( like mgag200 ) don't yet support drmModePageFlip.
This commit forgoes waiting for vblank and flips right away
in those cases. That prevents the hardware from freezing up the screen,
but does mean there will be some visible tearing.
https://bugzilla.gnome.org/show_bug.cgi?id=746042
We can't just destroy and replace the EGL and gbm surfaces while
they are still in use i.e. while there is a pending flip. In fact, in
that case, we were calling gbm_surface_destroy() on a surface that
still had the front buffer locked and then, on the flip handler,
gbm_surface_release_buffer() for a buffer that didn't belong to the
new surface.
Instead, we still allocate new surfaces when requested but they only
replace the old ones on the next swap buffers when we're sure that the
previous flip has been handled and buffers properly released.
Currently the code queries the current msc then tries to approximate the
value of the next msc satisfing the modulus 2 for when to wait. This
introduces some instability as the msc may tick over during the
roundtrip leading to a 32ms wait instead of a 16ms wait. This happens
often enough to cause jerky animations, and affect gnome-shell-perf-tool.
A simpler solution is just use a single roundtrip by using WaitForMsc to
ask the driver to compute the next vblank itself.
Cc: Owen W. Taylor <otaylor@fishsoup.net>
Cc: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Robert Bragg <robert@sixbynine.org>
Add cogl_texture_pixmap_x11_new_left() and
cogl_texture_pixmap_x11_new_right() (which takes the left texture
as an argument) for texture pixmap rendering with stereo content.
The underlying GLXPixmap is created using a stereo visual and shared
between the left and right textures.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
If we want to show quad-buffer stereo with Cogl, we need to pick an
appropriate fbconfig for creating the CoglOnscreen objects. Add
cogl_onscreen_template_set_stereo_enabled() to indicate whether
stereo support is needed.
Add cogl_framebuffer_get_stereo_mode() to see if a framebuffer was
created with stereo support.
Add cogl_framebuffer_get_stereo_mode() to pick whether to draw to
the left, right, or both buffers.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
An application might for whatever reason want to control a specific output
directly and have cogl only swap the other outputs if any. So add an api that
allows setting a crtc to be ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=730536
The surfaceless context extension can be used to bind a context
without a surface. We can use this to avoid creating a dummy surface
when the CoglContext is first created. Otherwise we have to have the
dummy surface so that we can bind it before the first onscreen is
created.
The main awkward part of this patch is that theoretically according to
the GL and GLES spec if you first bind a context without a surface
then the default state for glDrawBuffers is GL_NONE instead of
GL_BACK. In practice Mesa doesn't seem to do this but we need to be
robust against a GL implementation that does. Therefore we track when
the CoglContext is first used with a CoglOnscreen and force the
glDrawBuffers state to be GL_BACK.
There is a further awkward part in that GLES2 doesn't actually have a
glDrawBuffers state but GLES3 does. GLES3 also defaults to GL_NONE in
this case so if GLES3 is available then we have to be sure to set the
state to GL_BACK. As far as I can tell that actually makes GLES3
incompatible with GLES2 because in theory if the application is not
aware of GLES3 then it should be able to assume the draw buffer is
always GL_BACK.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
(cherry picked from commit e5f28f1e75db9bdc4f2688f420a74f908f96cf76)
Conflicts:
cogl/winsys/cogl-winsys-egl-kms.c
cogl/winsys/cogl-winsys-egl-x11.c
Some features that were previously available as an extension in GLES2
are now in core in GLES3 so we should be able to specify that with the
gles_availability mask of COGL_EXT_BEGIN so that GL implementations
advertising GLES3 don't have to additionally advertise the extension
for us to take advantage of it.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
(cherry picked from commit 4d892cd97558da61ba526f947ac0555ebab632d2)
When a new CoglAtlasTexture tries to fit into an existing CoglAtlas
it should make sure the atlas stays valid while it expands.
https://bugzilla.gnome.org/show_bug.cgi?id=728064
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 2eec9758f67e9073371c2edd63379324849373c4)
This can happen when we dpms off the output or when login1 takes away
drm master status from our drm fd. In either case, we need to call
the swap notify handler so that the compositor dosn't get stuck waiting
for that notification. The compositor should stop repainting shortly in
both cases, as it's either going into dpms off mode or vt switching away.
https://bugzilla.gnome.org/show_bug.cgi?id=728979
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This environment variable predates the reliable platform detection in mesa
and typically just causes crashes when the specified platform doesn't
match what's passed in. Aside from being unecessary and problematic
it also leaks into the GNOME session, preventing clients from
automatically detecting the wayland platform.
https://bugzilla.gnome.org/show_bug.cgi?id=728978
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Prevent Cogl function names from being mangled when a C++ compiler is
being used by adding some missing COGL_{BEGIN,END}_DECLS guards.
https://bugzilla.gnome.org/show_bug.cgi?id=728628
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Commit 1b2dd815 (Registers gtypes for all public objects and structs)
introduced GCCism's in its use of varargs, which broke the build of Cogl
on other non-GCC compilers, such as Visual Studio.
Define the COGL_GTYPE_DEFINE_BASE_CLASS and COGL_GTYPE_DEFINE_CLASS macros
using ISO-style varargs so that the build of Cogl can be fixed on non-GCC
compilers.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Remove #pragma directives that causes any applications that use Cogl to
link to the SDL libraries when Cogl was built with the SDL winsys. This is
mainly due to the availability of both SDL-1.x and SDL-2.x support in the
SDL winsys, where different libraries are linked for SDL-1.x and SDL-2.x.
To avoid having to link to the SDL/SDL2 libraries when the application code
is not directly using SDL/SDL2, define SDL_MAIN_HANDLED in the CFLAGS so
that SDL's wrapper main() implementation will not be used when the
application is being built.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit c3035912833eabe1f6dadbea23c78e595aac79dc)
In Lionel's work for supporting introspection better for Cogl, a number of
public symbols were added for Cogl and Cogl-Path, so add these symbols to
cogl.symbols and cogl-path.symbols so that they can be exported, which will
fix the build of the Cogl conformance test and the introspection files
for the Windows-based builds.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This macro is internal to gobject so using it risks breaking Cogl if
glib changes its API. Instead we just use its expansion. Note that
glib provides two expansions for this depending on the glib version
but this only uses the one for older versions.
Reviewed-by: Robert Bragg <robert.bragg@intel.com>
This adds much more comprehensive support for gobject-introspection
based bindings by registering all objects as fundamental types that
inherit from CoglObject, and all structs as boxed types.
Co-Author: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Remove the symbols that are now in cogl-path (where cogl-path.symbols
already include), and add the symbols that were added to the Cogl API.
Also add internal symbols as required by cogl-path and cogl-pango.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The DriverCallback is a function that is defined by the Windows SDK 8.0+
headers, which was initially used for device driver development. The use
of DriverCallback would cause a clash, causing things to break when built
with newer Windows SDKs, so rename DriverCallback to CoglDriverCallback to
avoid this problem.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
To help facilitate integration with third party frameworks this exposes
the EGL context and display to applications as well as the GLX context.
(Note that the GLX display is already available via
cogl_xlib_renderer_get_display())
This adds a new top-level <cogl/cogl-glx.h> header that needs to be
included explicitly to access the glx specific api.
Anyone using these apis will be responsible for checking that Cogl
is indeed using EGL or GLX by calling cogl_renderer_get_winsys_id()
This will enable GStreamer, for example, to be able to create a GL
context that shares resources with Cogl's context.
https://bugzilla.gnome.org/show_bug.cgi?id=724992
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This splits out the GLeglImageOES define in cogl-egl.h into a private
cogl-egl-private.h header and updates the guards in cogl-egl.h to be
consistent with other top-level headers where we need to be careful
about how __COGL_H_INSIDE__ is defined and undefined, esp when the
gobject introspection scanner is running.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This ensures we use EGLNativeWindowType and EGLNativeDisplayType
everywhere instead. The previous names come from EGL 1.2 but it seems
reasonable to require more recent EGL versions. If someone wanted to add
compatibility for EGL 1.2 later it would be straightforward to define
the new names to the old.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
SDL2 supports selecting between full OpenGL or OpenGL ES 1/2 but our
selection code was written before SDL 2.0 was officially released and
since then a new SDL_GL_CONTEXT_PROFILE_MASK attribute was added and
we have to explicitly set the SDL_GL_CONTEXT_MINOR_VERSION attribute.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds a new COGL_FEATURE_ID_BUFFER_AGE feature id that can be used
to determine if cogl_onscreen_get_buffer_age() will ever return an age
other than 0. This should be used instead of querying the winsys feature
via cogl_clutter_winsys_has_feature().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
We have an #ifdef EGL_WL_bind_wayland_display guard in
cogl-winsys-egl-feature-functions.h to avoid referencing wayland types
when the EGL header doesn't know about them, but somehow this guard also
ended up around the KHR_create_context and EXT_buffer age features too
even though they aren't wayland specific.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This winsys feature flag is exposed via the deprecated
cogl_clutter_winsys_has_feature function and Clutter is curently
relying on it. Previously the EGL winsys was only setting the internal
COGL_EGL_WINSYS_FEATURE_BUFFER_AGE flag and there was no mapping to
the public flag. Therefore the feature would only be used on GLX. This
patch just adds the mapping.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 8418e98b2b1b25515a961ad1bb9f0c4770d6eb1d)
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 7bc7ea4cb5e8134a3aeed9615477f4152b558509)
Conflicts:
cogl/winsys/cogl-winsys-egl-kms.c
Instead of spinning forever, do a roundtrip, which guarantees that the
global messages have been sent by the time we read the sync message.
If the proper globals aren't initialized yet, error out immediately. This
does mean that users can't use CoglOnscreen with foreign custom surface
types without xdg_shell, but when a use case comes for this, we'll
investigate then...
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit af9057d35f331e2c9509958fb40627917c477b80)
Since the Cogl 1.18 branch is actively maintained in parallel with the
master branch; this is a counter part to commit 1b83ef938fc16b which
re-licensed the master branch to use the MIT license.
This re-licensing is a follow up to the proposal that was sent to the
Cogl mailing list:
http://lists.freedesktop.org/archives/cogl/2013-December/001465.html
Note: there was a copyright assignment policy in place for Clutter (and
therefore Cogl which was part of Clutter at the time) until the 11th of
June 2010 and so we only checked the details after that point (commit
0bbf50f905)
For each file, authors were identified via this Git command:
$ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD
We received blanket approvals for re-licensing all Red Hat and Collabora
contributions which reduced how many people needed to be contacted
individually:
- http://lists.freedesktop.org/archives/cogl/2013-December/001470.html
- http://lists.freedesktop.org/archives/cogl/2014-January/001536.html
Individual approval requests were sent to all the other identified authors
who all confirmed the re-license on the Cogl mailinglist:
http://lists.freedesktop.org/archives/cogl/2014-January
As well as updating the copyright header in all sources files, the
COPYING file has been updated to reflect the license change and also
document the other licenses used in Cogl such as the SGI Free Software
License B, version 2.0 and the 3-clause BSD license.
This patch was not simply cherry-picked from master; but the same
methodology was used to check the source files.
Not doing so leads to the following error, if stddef.h is not included
indirectly through EGL headers:
| libdrm/drm.h:132:2: error: unknown type name 'size_t'
| size_t name_len; /**< Length of name buffer */
Signed-off-by: Andreas Oberritter <obi@saftware.de>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 55c82476a93366a3e7d1a2537fccc3a7aab87c66)
The _cogl_egl_texture_2d_new_from_image function has a CoglError
argument which implies that it is unlike the other texture
constructors and returns errors immediately rather than having a
delayed-allocation mechanism. cogl_wayland_texture_2d_new_from_buffer
which calls it is also like this. We can't rely on delayed-allocation
semantics for this without changing the applications because the
texture needs to be allocated before the corresponding EGLImage is
destroyed. This patch just makes it immediately allocate.
A better patch might be to remove the error argument to make it
obvious that there are delayed-allocation semantics and then fix all
of the applications.
This was breaking Cogland and Mutter.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 0206c03d54823b2f6cbb2aa420d07a4db9bcd8a3)
The previous implementation was dereferencing the sample pointer in
order to get the offset to subtract from the member pointer. The
resulting value is then only used to get a pointer to the member in
order to calculate the offset so it doesn't actually read from the
memory location and shouldn't cause any problems. However this is
probably technically invalid and could have undefined behaviour. It
looks like clang takes advantage of this undefined behaviour and
doesn't actually offset the pointer. It also generates a warning when
it does this.
This patch splits the _cogl_container_of macro into two
implementations. Previously the macro was always used in the list
iterator macros like this:
SomeType *sample = _cogl_container_of(list_node, sample, link)
Instead of doing that there is now a new macro called
_cogl_list_set_iterator which explicitly assigns to the sample pointer
with an initial value before assigning to it again with the real
offset. This redundant initialisation gets optimised out by compiler.
The second macro is still called _cogl_container_of but instead of
taking a sample pointer it just directly takes the type name. That way
it can use the standard offsetof macro.
https://bugzilla.gnome.org/show_bug.cgi?id=723530
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 1efed1e0a2bce706eb4901979ed4e717bb13e4e2)
The declaration of INTEL_swap_event was treating winsys features as
if they were a bitfield, but they aren't. The end result was that
instead of reporting two features when INTEL_swap_event is present,
we report none.
https://bugzilla.gnome.org/show_bug.cgi?id=719741
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Since 248a76f5eac7e5ae4fb45208577f9a55360812a7 cogl.h can no longer be
included in internal source files so the WGL winsys was no longer
compiling.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 91af97a2a27ab5ad3e7eaabebd03503b685d4d42)
This adds COGL_PIXEL_FORMAT_RG_88 and COGL_TEXTURE_COMPONENTS_RG in
order to support two-component textures. The RG components for a
texture is only supported if COGL_FEATURE_ID_TEXTURE_RG is advertised.
This is only available on GL 3, GL 2 with the GL_ARB_texture_rg
extension or GLES with the GL_EXT_texture_rg extension. The RG pixel
format is always supported for images because Cogl can easily do the
conversion if an application uses this format to upload to a texture
with a different format.
If an application tries to create an RG texture when the feature isn't
supported then it will raise an error when the texture is allocated.
https://bugzilla.gnome.org/show_bug.cgi?id=712830
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 568677ab3bcb62ababad1623be0d6b9b117d0a26)
Conflicts:
cogl/cogl-bitmap-packing.h
cogl/cogl-types.h
cogl/driver/gl/gl/cogl-driver-gl.c
tests/conform/test-read-texture-formats.c
tests/conform/test-write-texture-formats.c
The following changes are made to the documentation for CoglTexture:
• The description of the default value for the components property is
changed to say that it is always RGBA for textures created by the
‘_with_size’ textures. Previously it said that the default is based
on the pixel format used the first time data is set on the texture,
but this is only true if the data is set using a constructor.
• Added documentation for the CoglTextureComponents enum.
• Changed it to say that it _specifies_ what components are required
for sampling rather than determinging [sic] them.
• Added ‘Since: 1.18’ to
cogl_texture_{set,get}_{components,premultiplied}
• Changed the since tag for CoglTextureError from 2.0 to 1.8.
• Added documentation for COGL_TEXTURE_ERROR_{FORMAT,TYPE}.
• Added the following to the cogl2-sections.txt file:
COGL_TEXTURE_ERROR
CoglTextureError
cogl_texture_allocate
cogl_texture_set_components
cogl_texture_get_components
cogl_texture_set_premultiplied
cogl_texture_get_premultiplied
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 2f12c4329c519fa14b927b2dcd708dddcc903c32)
Previously when a pipeline is added to the cache it would never be
removed. If the application is generating a lot of unique pipelines
this can end up effectively leaking a large number of resources
including the GL program objects. Arguably this isn't really a problem
because if the application is generating that many unique pipelines
then it is doing something wrong anyway. It also implies that it will
be recompiling shaders very often so the cache leaking will likely be
the least of the problems.
This patch makes it keep track of which pipelines in the cache are in
use. The cache now returns a struct representing the entry instead of
directly returning the pipeline. This entry contains a usage counter
which the pipeline backends can use to mark when there is a pipeline
alive that is using the cache entry. When the hash table decides that
it's a good time to prune some entries, it will make a list of all of
the pipelines that are not in use and then remove the least recently
used half of the pipelines. That way it is less likely to remove
pipelines that the application is actually regenerating often even if
they aren't in use all of the time.
When the cache is pruned the hash table makes a note of how small the
cache could be if it removed all of the unused pipelines. The hash
table starts pruning when there are more entries than twice this
minimum expected size. The idea is that if that case it hit then the
hash table is more than half full of useless pipelines so the
application is generating lots of redundant pipelines and it is a good
time to remove them.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit c21aac22992bb7fef5a8d0913130b8245e67f2eb)
Conflicts:
cogl/driver/gl/cogl-pipeline-fragend-glsl.c
cogl/driver/gl/cogl-pipeline-progend-glsl.c
cogl/driver/gl/cogl-pipeline-vertend-glsl.c
cogl/driver/gl/gl/cogl-pipeline-fragend-arbfp.c
This fixes the cogl_texture_get_components() prototype to have a return
type of CoglTextureComponents instead of CoglBool which was probably a
copy and paste error.
(cherry picked from commit 55b09f8a939db71ee5ff41afa0ed08cbe937a4ec)
This updates the cogl_texture_rectangle_new_with_size() api in line with
master to be consistent with other texture constructors. This removes
the internal_format and error arguments and allows the texture to be
allocated lazily which means the texture can be configured with apis
like cogl_texture_set_components() and cogl_texture_set_premultiplied()
before it is allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
test-path for example uses COGL_ENABLE_EXPERIMENTAL_2_0_API to access
the 2.0 CoglPath api but also uses deprecated framebuffer api such as
cogl_push/pop_framebuffer. Similarly clutter-backend.c builds with
COGL_ENABLE_EXPERIMENTAL_2_0_API and uses cogl_set_framebuffer().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves the framebuffer stack apis out of cogl-framebuffer.c into
cogl/deprecated/cogl-framebuffer-deprecated.c so cogl-framebuffer.c is
more in-line with the master branch to ease cherry picking patches.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves all of the automagic texture constructor prototypes from
cogl-texture.h into a new deprecated/cogl-auto-texture.h file. This also
moves cogl_texture_new_from_sub_texture() into
deprecated/cogl-auto-texture.c
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Texture allocation is now consistently handled lazily such that the
internal format can now be controlled using
cogl_texture_set_components() and cogl_texture_set_premultiplied()
before allocating the texture with cogl_texture_allocate(). This means
that the internal_format arguments to texture constructors are now
redundant and since most of the texture constructors now can't ever fail
the error arguments are also redundant. This now means we no longer
use CoglPixelFormat in the public api for describing the internal format
of textures which had been bad solution originally due to how specific
CoglPixelFormat is which is missleading when we don't support such
explicit control over the internal format.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 99a53c82e9ab0a1e5ee35941bf83dc334b1fbe87)
Note: there are numerous API changes for functions currently marked
as 'unstable' which we don't think are in use by anyone depending on
a stable 1.x api. Compared to the original patch though this avoids
changing the cogl_texture_rectangle_new_with_size() api which we know
is used by Mutter.
This introduces the internal idea of texture loaders that track the
state for loading and allocating a texture. This defers a lot more work
until the texture is allocated.
There are several intentions to this change:
- provides a means for extending how textures are allocated without
requiring all the parameters to be supplied in a single _texture_new()
function call.
- allow us to remove the internal_format argument from all
_texture_new() apis since using CoglPixelFormat is bad way of
expressing the internal format constraints because it is too specific.
For now the internal_format arguments haven't actually been removed
but this patch does introduce replacement apis for controlling the
internal format:
cogl_texture_set_components() lets you specify what components your
texture needs when it is allocated.
cogl_texture_set_premultiplied() lets you specify whether a texture
data should be interpreted as premultiplied or not.
- Enable us to support asynchronous texture loading + allocation in the
future.
Of note, the _new_from_data() texture constructors all continue to
allocate textures immediately so that existing code doesn't need to be
adapted to manage the lifetime of the data being uploaded.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6a83de9ef4210f380a31f410797447b365a8d02c)
Note: Compared to the original patch, the ->premultipled state for
textures isn't forced to be %TRUE in _cogl_texture_init since that
effectively ignores the users explicitly given internal_format which was
a mistake and on master that change should have been made in the patch
that followed. The gtk-doc comments for cogl_texture_set_premultiplied()
and cogl_texture_set_components() have also been updated in-line with
this fix.
When reading a texture back by first wrapping it as an offscreen
framebuffer and using _read_pixels_into_bitmap() we now make sure the
offscreen framebuffer has an internal format that matches the
meta-texture being read not that of the current sub-texture being
iterated. In the case of atlas textures the subtexture is a shared
texture whose format doesn't reflect the premultipled alpha status of
individual atlas-textures, nor whether the alpha component is valid.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6ee425d4f10acd8b008a2c17e5c701fc1d850f59)
CoglPixelFormat is not a good way of describing the internal
format of a texture because it's too specific given that we don't
actually have exact knowledge of the internal format used by the driver.
This makes cogl_texture_get_format private and in the future we'll
provide a better way of querying the channels and their precision.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ffde82981f22bd0185a7f33e1e6e1479f4c295b8)
Note: Since we can't break API compatibility on the 1.x branch this adds
a cogl/deprecated/cogl-texture-deprecated.c file with a
cogl_texture_get_format() wrapper around the private api. This also
moves the cogl_texture_get_rowstride() and cogl_texture_ref/unref()
functions that were previously deprecated into cogl-texture-deprecated.c
This defers checking the internal format and whether accelerated
migration is supported until allocating the texture.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 83b05cbe3969789bc3ec78480c0937a6722efbf1)
Instead of throwing a CoglError exception if an application tries to
allocate a zero size atlas texture this make that a programmer error
instead.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit d3eaeedc86d408669b81d6c43ef2b0ab9d859c85)
The plan is to defer a lot more work in creating a texture until
allocation time. This means that for some texture backends we might not
know until after allocation whether the texture is sliced or can support
hardware repeating. This makes sure we trigger an allocation if either
of these are queried.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 4868582812dbcd5125495b312d858f751fc31e9d)
The plan is to defer a lot more work in creating a texture until
allocation time. This means we wont be able to assume that all textures
being used to render must have already been allocated when data was
specified.
The latest point at which we will generally require a texture to be
allocated will be when we need to know the underlying GL handle for a
texture and so this updates cogl_texture_get_gl_texture() to ensure the
texture is allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 59f6fefc37524f492512a71b831760a218d9bb95)
The plan is to defer more of the work for creating a texture until
allocation time, but that means we won't be able to always assume
we can query the size of a texture when creating an offscreen
framebuffer from a texture (consider for example using
_texture_new_from_file() where the size isn't known until the file has
been loaded). This defers needing to know the size of the texture
underlying an offscreen framebuffer until calling
cogl_framebuffer_allocate().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9688e7dc1eeae3144729dfd4a4bf409620346bf4)
This ensures framebuffers are implicitly allocated when querying the
width, height or viewport width/height if the framebuffer's size is
currently unknown. The plan is to allow texture backends to defer
calculating the size of textures until they are allocated which in turn
means we won't know the size of offscreen framebuffers until the texture
has been allocated. Potentially we could be more specific about this in
the future and only ensure the texture is allocated, but for now it will
be simplest to just ensure the framebuffer is allocated.
Note: in the case of onscreen buffers which are always initialized with
a requested size we are careful to avoid triggering an allocation when
this is queried otherwise we will see recursion when the winsys code
queries the requested size during allocation.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f4b612f1b75e043f1852b9a32368cc37ab89308b)
Since we are planning on deferring more texture allocation work this
makes sure we don't query whether a texture is sliced until we know it
has been allocated.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit b742638a1ce581f5a2c9f15907361c3b0c1b178c)
This removes cogl_framebuffer_get_color_format() since the actual
internal format isn't strictly controlled by us. CoglFramebuffer::format
has been renamed to ::internal_format to make it clearer that it only
really represents the premultiplication status.
The plan is to make most of the work involved in creating a texture
happen lazily when allocating so this patch also changes
_cogl_framebuffer_init() to not take a format argument anymore since we
won't know the format of offscreen framebuffers until the framebuffer is
allocated, after the corresponding texture has been allocated. In the
case of offscreen framebuffers we now update the framebuffer
internal_format during allocation.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 8cc9e1c8bd2fac8b2a95087249c23c952d5e379f)
Note: Since we can't break API compatibility on the 1.x branch this
actually keeps the cogl_framebuffer_get_color_format() api but moves it
into a new deprecated/cogl-framebuffer-deprecated.c file and it now
returns the newly name ::internal_format.
The bug that prevented MESA_copy_sub_buffer to work for swrast /
llvmpipe got fixed in mesa 10.1 git so enable it for mesa 10.1+.
https://bugzilla.gnome.org/show_bug.cgi?id=721450
When landing the patch, it was tweaked to #include "cogl-version.h" to
avoid a compiler warning about COGL_VERSION_ENCODE being implicitly
defined. -- Robert Bragg
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e7e216b1d3d151acf3fed619bd759692a989b4b4)
Since we now have more time to ensure that Clutter is updated to check
for the now separate cogl-path package as part of its build
configuration we are now making the package split, in line with Cogl
master.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This makes it so that cogl-sdl.h is a top-level header no longer
automatically included by cogl.h. This avoids lots of warnings building
the conformance tests and examples due to SDL.h warning when
__STRICT_ANSI__ isn't defined.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f7536985437dc85c26b33d1bbe1b7f3d4b32476a)
This means that we can't cache the journal read_pixels optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=719582
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 550bae22d20c8d6d7cf1d090faa9c91619594077)
This reverts commit bc41489336.
The reason this was causing problems for Clutter is that it defines
COGL_ENABLE_EXPERIMENTAL_2_0_API which is meant to cause the Cogl
headers not to declare the deprecated API. The reverted patch moved
some additional clipping API to a deprecated header which was
previously being used by Clutter. Clutter was still successfully
compiling but with some warnings for the missing function
declarations. However when the binary is run the clipping would get
completely messed up because it would assume all of the arguments to
the functions are integers instead of floats and the wrong values
would be passed.
Clutter now has commit to make it use the 2.0 API instead of the
deprecated functions so the revert is no longer necessary.
https://git.gnome.org/browse/clutter/commit?id=705640367a5c2ae21405806bfa
Reviewed-by: Robert Bragg <robert@linux.intel.com>
When projecting the bounding rectangle of a primitive it was using the
modelview matrix twice instead of the modelview and projection
matrices so it was coming out with garbage.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 7e1f05c84013bb91248d691091df00f4f634c6cf)
This reverts commit ae9cd7ca01.
Pushing this for now so we can get gnome-shell working again without
memory corruption. Let's push a proper fix later for everybody.
This was added in 361bd516f3 late during the 1.10 cycle to
contain experimental functions that we should never have made public.
The plan was to remove them once we started working on 1.12 but it
looks like we never got around to doing that. Better late than never!
The header for the file was already removed in 7365c3aa77.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
There used to be a function called cogl_clip_stack_save in the public
API which was used when temporarily switching to an offscreen buffer
to save the clip state. This is no longer necessary because each
framebuffer has its own clip stack anyway so the function was removed
in master. However the code to maintain the stack of stacks was
retained. This patch removes it in an effort to simplify the code.
On the 1.18 branch this function is deprecated and the documentation
says that it does nothing. However that is incorrect because it does
actually the push clip stack. I think it would be safe to backport
this patch to the 1.18 branch and actually make it do nothing like it
is documented to do.
https://bugzilla.gnome.org/show_bug.cgi?id=719546
(cherry picked from commit 8655027fdcf03b02fcbbb02d179a0a88ed79c5b3)
This patch has some extra changes while backporting to the 1.18
branch. Here the cogl-clip-state file still contained some deprecated
functions. Instead of deleting the file completely it has been moved
to the deprecated folder. The declarations for this functions have
been moved from cogl1-context.h to a new deprecated/cogl-clip-state.h
header.
Conflicts:
cogl/Makefile.am
cogl/cogl-clip-state.c
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Adds cogl_wayland_texture_set_region_from_shm_buffer which is a
convenience wrapper around cogl_texture_set_region but it uses the
correct format to copy the data from a Wayland SHM buffer. This will
typically be used by compositors to update the texture for a surface
when an SHM buffer is attached. The ordering of the arguments is based
on cogl_texture_set_region_from_bitmap.
Based on a patch by Jasper St. Pierre.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit c76c1d136d2cac7f3d1331a4d1dc0dd0f06e812c)
Conflicts:
examples/cogland.c
This patch was accidentally added before it had any review and without
first going through master. Master now has a replacement patch with
some modifications. That will be cherry-picked to the 1.18 branch in a
subsequent commit.
This reverts commit af480a2b8b.
Previously the private feature flags were stored in an enum and we
already had 31 flags. Adding the 32nd flag would presumably make it
add -2³¹ as one of the values which might cause problems. To avoid
this we'll just use an fixed-size array of longs and use indices for
the enum values like we do for the public features.
A slight complication with this is in the CoglDriverDescription where
we were previously using a static intialised value to describe the set
of features that the driver supports. We can't easily do this with the
flags array so instead the features are stored in a fixed-size array
of indices.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d94cb984e3c93630f3c2e6e3be9d189672aa20f3)
Conflicts:
cogl/cogl-context-private.h
cogl/cogl-context.c
cogl/cogl-private.h
cogl/cogl-renderer.c
cogl/driver/gl/cogl-pipeline-opengl.c
cogl/driver/gl/gl/cogl-driver-gl.c
cogl/driver/gl/gl/cogl-pipeline-progend-fixed-arbfp.c
cogl/driver/gl/gles/cogl-driver-gles.c
cogl/driver/nop/cogl-driver-nop.c
This fixes the build with --enable-introspection. I'm not sure why
g-ir-scanner seems to parse all public headers in isolation instead of
being able take a more limited list of top-level public headers and
automatically parse all necessary #include directives but this means we
have to special case how we define and undefine __COGL_H_INSIDE__ to
subvert the guards we have in place for detecting misuse of the headers.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e0b2255876c1cf11d124d5ae37cbe9a6e43777f1)
This declares the interface types CoglFramebuffer, CoglBuffer,
CoglTexture, CoglMetaTexture and CoglPrimitiveTexture as void when
including the public cogl.h header so that users don't have to use lots
of C type casts between instance types and interface types.
This also removes all of the COGL_XYZ() type cast macros since they do
nothing more than compile time type casting but it's less readable if
you haven't seen that coding pattern before.
Unlike with gobject based apis that use per-type macros for casting and
performing runtime type checking we instead prefer to do our runtime
type checking internally within the front-end public apis when objects
are passed into Cogl. This greatly reduces the verbosity for users of
the api and may help reduce the chance of excessive runtime type
checking that can sometimes be a problem.
(cherry picked from commit 248a76f5eac7e5ae4fb45208577f9a55360812a7)
Since we can't break the 1.x api this version of the patch actually
defines compatible NOP macros within deprecated/cogl-type-casts.h
This patch doesn't look right because now nothing will ever set
clear_clip_dirty = TRUE. Presumably that would mean that if a
rectangle is drawn and then the journal is flushed before the
framebuffer is read, then it would think it could return the clear
color even though it shouldn't.
Perhaps a better approach would be to make a second version of
_cogl_framebuffer_mark_mid_scene that doesn't set the clear_clip_dirty
flag and call that from the journal instead. As this patch was pushed
without review and without first going into the master branch I think
it makes sense to just revert it and apply a new version to master.
This reverts commit 3eb63f67a3.
Leaving the clip bounds untouched means that it will retain the stale value
of whatever it was when we last had a clip; reset it so that it contains the
full framebuffer contents instead.
https://bugzilla.gnome.org/show_bug.cgi?id=712562
Add framebuffer methods cogl_framebuffer_[gs]et_depth_write_enabled()
and backend bits to pass the state on to glDepthMask().
This allows us to enable or disable depth writing per-framebuffer, which
if disabled saves us some work in glClear(). When rendering, the flag
is combined with the pipeline's depth writing flag using a logical AND.
Depth writing is enabled by default.
https://bugzilla.gnome.org/show_bug.cgi?id=709827
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 71406438c5357eb4e0ef03e940c5456a536602a0)
Depending on what version of Mesa you have then eglQueryWaylandBuffer
may take a wl_buffer or wl_resource argument and the EGL header will
only forward declare the corresponding type.
The use of wl_buffer has been deprecated and so internally we assume
that eglQueryWaylandBuffer takes a wl_resource but for compatibility we
forward declare wl_resource in case we are building with EGL headers
that still use wl_buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=710926
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9bd1ee544667cfe7ecae479ec7f778446dd8f326)
cogl_is_atlas_texture is supposed to be exported from the DLL/.so, so
update the cogl.symbols file to ensure this.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 13e037f096de5742db769500b4c0018249d8f8e4)
This makes cogl_framebuffer_set_color_mask immediately bail out if the
given mask equals the framebuffer's current mask, since the cost of
flushing the journal and flushing the gl state will hugely outweigh the
cost of the check.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 925174d99df7f1f4b11098e748bcc23eaa396a21)
This updates the definition of _COGL_STATIC_ASSERT to just use
_Static_assert if available or be NOP if not. We no longer worry about
supporting static assertions with older compilers. This fixes some
verbose warnings that newer compilers were giving with the old typedef
based static assertion method.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 645e3607ea7f210d6dcb9d217204790051de7c82)
When a pipeline is notified of a change we now make sure to notify all
progends of that change not just the progend directly associated with
that pipeline. A pipeline can have private state associated with it from
multiple progends because descendants will always try and cache state on
ancestors to maximize the chance that the state can later be re-used.
Descendants may be using different progends than the ancestors that they
cache state with.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 873939a18934185fb3c9c84c373cb86d1278add7)
This avoids including wayland-server.h in cogl-display-private.h which
avoid lots of compile time warnings that wl_buffer is deprecated. The
problem is that wl_buffer is also exposed in the client side headers and
isn't deprecated for clients. If we end up including the client and
server headers in the same compilation unit we can get conflicting
definitions.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 60fcd9c87cf5d8ae8c41134217ee0e1fa2fbd46e)
wl_buffer has been deprecated in the server API and instead
compositors should be directly passing the wl_resource pointer to
eglQueryWaylandBuffer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f13278bcf3f1475b7afc7d55a5218f409d119658)
Commit 50d1285b updated the wl_shm enum values but left
one out. Update it to fix the build on big-endian.
https://bugzilla.gnome.org/show_bug.cgi?id=710135
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 9246286846d0428b03e646b2f5ec14f0eff4edc6)
This makes a start on clearly factoring the deprecated code of core Cogl
into a deprecated/ directory. Ideally we want to get to the point where
all code here can be re-worked in terms of the public 2.0 api so that it
can be kept indefinitely for cogl 1.x api compatibility without
cluttering the core code base itself. If we can do this then we can
avoid maintaining the Cogl 1.x branches in parallel with master which
would reduce the maintenance effort.
Commit 7b25c8f5ca mistakenly added a reference to a
COGL_GTYPE_DEFINE_CLASS() macro that does not yet exist so this patch
removes it.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
When running in a purely swrast environment (such as with
LIBGL_ALWAYS_SOFTWARE), the extension is not exposed by mesa,
but wayland is still possible with wl_shm.
https://bugzilla.gnome.org/show_bug.cgi?id=704750
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 8d4e4b0e8062708cece4d4c929abccc492ee21cc)
It was an oversight when making the CoglAtlasTexture api public that we
continued to use the COGL_TEXTURE_INTERNAL_DEFINE macro. This updates
the code to now use COGL_TEXTURE_DEFINE which means the
cogl_is_atlas_texture() function will now be exported in the public api.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Lionel Landwerlin <llandwerlin@gmail.com>
(cherry picked from commit ecbe209f48be80fe45b48f92b277a2aee08d5704)
The recommended usage model for rendering pipelines with minor changes
is to make a copy of a base pipeline just before rendering and then
modify that. The new pipeline can then be used as the base pipeline
for the next paint. Currently this has a known problem when modifying
uniform values in that Cogl won't prune the redundant ancestry and
instead it will end up with an ever-growing chain of pipelines. This
is particularly bad for something like CoglGST where it could also end
up leaking textures for the video frames if the pipelines are used to
render video.
The patch adds a test case for that situation so that we won't forget
about the problem. The test is maked as a known failure. Additionally
the patch adds a similar test for setting the blend constant to
constrast the test with some state that does work correctly.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 2550181543389d6e9e1cb9618d17cd352a0cf9b6)
This reverts the change in semantics for cogl_texture_new_with_size so
that it goes back to allocating textures synchronously and returning
NULL if there was a failure to allocate. Only the new/2.0 texture apis
will have the lazy allocation behaviour so we avoid breaking existing
code. This also fixes a potential crasher by removing a code path
that was passing NULL to cogl_texture_allocate() that would have caused
and abort if there were an error.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds a #define for gl_PointCoord to all shaders so that it can be
accessed with a name in the Cogl namespace.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit c28fc054788e88627bcc2346f4c4c368870ff777)
Previously we would only add the #version pragma to shaders when
point sprite texture coordinates are enabled for a layer so that we
can access the gl_PointCoord builtin. However I don't think there's
any good reason not to just always request GLSL version 1.2 if it's
available. That way applications can always use gl_PointCoord without
having to enable point sprite texture coordinates.
This adds a glsl_version_to_use member to CoglContext which is used to
generate the #version pragma as part of the shader boilerplate. On
desktop GL this is set to 120 if version 1.2 is available, otherwise
it is left at 110. On GLES it is always left as 100.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e4dfe8b07e8af111ecbcb0da20ff2a2875a2b5d0)
Conflicts:
cogl/driver/gl/gl/cogl-driver-gl.c
The documentation for the builtin varyings for the texture coordinates
was wrongly claiming that the varyings are stored in an array. This
was changed in e55b64a9cdc9 so that each layer gets its own
independent varying.
The documentation was also referring to texture units instead of layer
numbers. The texture units are no longer publicly exposed in the
shaders and instead everything should in theory be expressed in terms
of layer numbers.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit bf6b509c340bdc3be30e1a81fb96710b3176e9dc)
The deprecation macros need to be before the function prototype on
Visual Studio, and is also accepted by GCC.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Add the symbols that were added to the public Cogl API, and remove the
export of an internal API that was also removed. Unfortunately
_cogl_system_error_quark needs to be exported for the conformance test
programs.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Cogl-Path was split out from the main Cogl library to become a standalone
library, but many libraries/appplications using Cogl (such as Clutter)
expects that Cogl-Path is still in Cogl. Define
COGL_HAS_COGL_PATH_SUPPORT here, as it will always be needed, at least for
the 1.16 release series, so that builds of items using Cogl would not
break, such as Clutter.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The autotools variables to substitute for versioning in 1.16 is wrong, so we
have incorrect versioning info during a release as the variables are for
Cogl-2.x. Fix this so we can have the correct versioning info for the
Cogl/Cogl-Pango DLLs during a release.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The cogl-texture-private.h needs to be included as
_cogl_texture_needs_premult_conversion, so that we can avoid implicit
declaration warnings of that symbol (aka C4013 on MSVC).
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 4afe9dc1fea646e2a9576f9a0dbd1ffafa40485b)
So we don't read an initializes value later on. Caught by valgrind:
Conditional jump or move depends on uninitialised value(s)
_cogl_object_texture_rectangle_indirect_free (cogl-texture-rectangle.c:105)
_cogl_object_context_indirect_free (cogl-context.c:453)
...
main (text.c:149)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 90415aae9495749a2a9e85fb17425a3c7f6a08c8)
Mesa has started getting picky about specifying the precision for
floating types in the fragment shader. We already have a default
precision specifier in all the fragment shaders but apparently this
wasn't working because it is only used when the __VERSION__ define is
100 and Mesa is reporting 110. Regardless of whether Mesa is doing the
right thing or not I think it makes sense to use GL_ES instead of
__VERSION__ because we will also need the precision specifier if we
start requesting GLSL 3.0. The GLES specification explictly states
that GL_ES will only be defined for GLES and this is similar to what
the internal meta shaders do in Mesa.
http://cgit.freedesktop.org/mesa/mesa/commit/?id=cabd45773b58d6aa482
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 37f5205739cfb0745ea74dedaec117081ba0088b)
Since e07d0fc7441 the COGL_DRIVER environment variable was able to
override the application's driver selection. This doesn't seem like a
good idea because if the application is specifying a driver explicitly
then presumably it can not work with any other driver. This patch
changes it so that if a driver is selected in the configuration and by
the application then they must match, otherwise it will fail with a
CoglError.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 4e0942d74c8d69aa48e0176bfecf27f64a950d0f)
Only COGL_RENDERER_CONSTRAINT_SUPPORTS_COGL_GLES2 affects the driver
selection and all of the the other constraints are only relevant to
the winsys selection. However Cogl was trying to apply all of the
constraints to the driver selection which meant that if any other
constraint was specified then it would always fail. This patch makes
the driver selection filter out all other constraints based on a mask
defined in cogl-renderer-private.h.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f07febc8913b97fb828e7f2cc2857813af2d3657)
Currently it's only possible to set an onscreen template on a
CoglDisplay by passing a template to cogl_display_new(). For
applications that want to deal with fallbacks then they may want to
replace the onscreen template so this adds a
cogl_display_set_onscreen_template() function.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f307c9545791dae5472a9568fef6b31b3bf52854)
This updates the static assertion in cogl-renderer.c to only check that
the flags will fit in 32 bits instead of asserting the type has the same
size as an unsigned long.
(cherry picked from commit c6893fa3c9eda0f13b79d3a1fc03f8b79c42a8f6)
WebGL doesn't allow you to separately attach buffers to the
STENCIL_ATTACHMENT and DEPTH_ATTACHMENT framebuffer attachment points
and instead requires you to use the DEPTH_STENCIL_ATTACHMENT whenever
you want a depth and stencil buffer.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ec7b6360c9c4e45e0b113f9dca7bb1502e7e93be)
This adds a COGL_DRIVER_WEBGL enum and a new driver description for
webgl in cogl-renderer.c. This also adds a COGL_DRIVER_FLAG_OPENGL_WEB
driver flag and a HAVE_COGL_WEBGL define which we can start to use to
handle special cases where webgl differs from gles2.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 2c167b7a4ee56241827322bbe7cb287b0628437c)
This adds a table of driver descriptions to cogl-renderer.c in order of
preference and when choosing what driver to use we now iterate the table
instead of repeating boilerplate checks. For handling the "default driver"
that can be specified when building cogl and handling driver overrides
there is a foreach_driver_description() that will make sure to iterate
the default driver first or if an override has been set then nothing but
the override will be considered.
This patch introduces some driver flags that let us broadly categorize
what kind of GL driver we are currently running on. Since there are
numerous OpenGL apis with different broad feature sets and new apis
may be introduced in the future by Khronos then we should tend to
avoid using the driver id to do runtime feature checking. These flags
provide a more stable quantity for broad feature checks.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e07d0fc7441dddc3f0a2bc33a6a37d62ddc3efc0)
Add API to allow complex applications using the KMS backend
to go almost straight to direct configuration (which is not possible
because Cogl needs to be in charge of buffers and FB objects).
https://bugzilla.gnome.org/show_bug.cgi?id=705837
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 52fb8e1c33d8c83c731c05cee767928fdd5991d7)
This now updates the guard to ignore whether
COGL_ENABLE_EXPERIMENTAL_2_0_API is defined since we need to work for
clutter which does define that, as well as clutter users that don't.
cogl.h was meant to include cogl-path.h so long as
COGL_ENABLE_EXPERIMENTAL_2_0_API is not defined but it was actually
requiring it to be defined which was breaking clutter applications.
The eglTerminate code in Mesa will try to destroy the wl_drm object
which involves using data structures in the wl_display. Cogl was
disconnecting the display before calling eglTerminate which meant that
this would end up accessing potentially garbage data.
https://bugzilla.gnome.org/show_bug.cgi?id=705591
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 358d85f35d0fe36698b758163729c4551fe5fd25)
The deprecation macros, which expand to __declspec (deprecated) on Visual
Studio, is expected to be before the return type of the function which
is annotated by them, and having the deprecation macros there is also
accepted by GCC as well.
This will fix the builds of all applications/libraries using Cogl under
Visual Studio,
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Add and rename the symbols that have been added/renamed during the
development cycle, and also remove those that have been dropped during the
process.
Also continue the quest of purging from the exports lists of the internal
APIs as some of those are no longer referenced by other Cogl components.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Unfortunately named initializers is a feature that is not supported by
all compilers (such as pre-2013 Visual Studio) so avoid using that.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 5a5659f9861dfe7a4808f2a5284de8fe6175bec2)
Use the HAVE_STRINGS_H check before we include strings.h, as it is not
universally available.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit ff65144c84a16f9470d3f3931dc91cc9a6ef5938)
...For both the regular WGL winsys and SDL winsys builds, that
COGL_HAS_GTYPE_SUPPORT is defined, so that the builds won't break as
Visual Studio builds do assume an existing installation of GLib.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit ef41aea2796315a47693bf278f08b41ca6703566)
Full GL treats the position attribute specially and requires that it
must be bound to generic attribute location 0 unlike GLES 2.0 or
GL 3.2 core. We now make sure to unconditionally bind the
cogl_position_in attribute to location 0 before linking any glsl program
in cogl.
For reference the relevant part of the GL 3.0 spec that covers these
semantics is Section 2.7 "Vertex Specification" pg 27
After this change there was one remaining problem in
test-custom-attributes where the test_short_verts() test was using its
own "pos" attribute instead of cogl_position_in and so cogl wasn't able
to ensure it would be bound to location 0.
This updates the test to use cogl_position_in but to work around the
fact that glVertexPointer doesn't support UNSIGNED_SHORT components we
force the test to use the glsl backend by setting a shader snippet on
the pipeline.
https://bugs.freedesktop.org/show_bug.cgi?id=67548
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 992ef7b3b49ebb56adde2133bb36330c04133a3f)
This renames cogl_offscreen_new_to_texture to
cogl_offscreen_new_with_texture. The intention is to then cherry-pick
this back to the cogl-1.16 branch so we can maintain a parallel
cogl_offscreen_new_to_texture() function which keeps the synchronous
allocation semantics that some clutter applications are currently
relying on.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ecc6d2f64481626992b2fe6cdfa7b999270b28f5)
Note: Since we can't break the 1.x api on this branch this keeps a
thin shim around cogl_offscreen_new_with_texture to implement
cogl_offscreen_new_to_texture with its synchronous allocation
semantics.
The API says that it should return NULL on failure but it does not do that
due to the lazy allocation.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=703174
This splits out the cogl_path_ api into a separate cogl-path sub-library
like cogl-pango and cogl-gst. This enables developers to build Cogl with
this sub-library disabled if they don't need it which can be useful when
its important to keep the size of an application and its dependencies
down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path
have been renamed to cogl_path_{fill,stroke}.
There were a few places in core cogl and cogl-gst that referenced the
CoglPath api and these have been decoupled by using the CoglPrimitive
api instead. In the case of cogl_framebuffer_push_path_clip() the core
clip stack no longer accepts path clips directly but it's now possible
to get a CoglPrimitive for the fill of a path and so the implementation
of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as
a shim that first gets a CoglPrimitive and uses
cogl_framebuffer_push_primitive_clip instead.
We may want to consider renaming cogl_framebuffer_push_path_clip to
put it in the cogl_path_ namespace.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f)
So as to avoid breaking the 1.x API or even the ABI since we are quite
late in the 1.16 development cycle the patch was modified to build
cogl-path as a noinst_LTLIBRARY before building cogl and link the code
directly into libcogl.so as it was previously. This way we can wait
until the start of the 1.18 cycle before splitting the code into a
separate libcogl-path.so.
This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid
breaking the 1.x API/ABI.
Otherwise, if we try egl-wayland first, we get the environment
variable from that, which crashes mesa trying to open the gbm device
as a wayland display.
https://bugzilla.gnome.org/show_bug.cgi?id=705836
Almost nothing draws attributes directly and for those things that do
it's trivial to adapt them to instead draw via the cogl_primitive api.
This simplifies the Cogl api a bit.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 7395925bcc01aad6c695fd0d9af78b784b3c64d4)
Conflicts:
cogl/cogl-framebuffer.c
cogl/cogl-framebuffer.h
When splitting out the CoglPath api we saw that we would be left with
inconsistent drawing apis if the drawing apis in core Cogl were lumped
into the cogl_framebuffer_ api considering other Cogl sub-libraries or
that others will want to create higher level drawing apis outside of
Cogl but can't use the same namespace.
So that we can aim for a more consistent style this adds a
cogl_primitive_draw() api, comparable to cogl_path_fill() or
cogl_pango_show_layout() that's intended to replace
cogl_framebuffer_draw_primitive()
Note: the attribute and rectangle drawing apis are still in the
cogl_framebuffer_ namespace and this might potentially change but in
these cases there is no single object representing the thing being drawn
so it seems a more reasonable they they live in the framebuffer
namespace for now.
Note: the cogl_framebuffer_draw_primitive() api isn't removed by this
patch so it can more conveniently be cherry picked to the 1.16 branch so
we can mark it deprecated for a short while. Even though it's marked as
experimental api we know that there are people using the api so we'd
like to give them a chance to switch to the new api.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 418912b93ff81a47f9b38114d05335ab76277c48)
Conflicts:
cogl-pango/cogl-pango-display-list.c
cogl/Makefile.am
cogl/cogl-framebuffer.c
cogl/cogl-pipeline-layer-state.h
cogl/cogl2-path.c
cogl/driver/gl/cogl-clip-stack-gl.c
This updates cogl_bitmap_new_for_data() to calculate the rowstride from
the width and bpp if the given rowstride is 0, to be consistent with how
the texture apis work.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 1c809210092a8c5e223edfcab1e378b205cf35d6)
In preparation for removing the automagic cogl-auto-texture apis this
adds a more minimal version of the cogl_texture_new_with_size code to
cogl-atlas.c for creating textures used to migrate images out of an
atlas and to cogl-texture-pixmap-x11.c.
Note: It turned out that both of these minimal versions were the same so
I did consider keeping a shared utility, but since the implementations
are very small and potentially due to the differing requirements for
atlas and pixmap-x11 textures we might even want them to differ later I
chose to keep them separate.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6d64307483713e7a5a7ef554275619def51b840f)
Conflicts:
cogl/cogl-atlas.c
cogl/winsys/cogl-texture-pixmap-x11.c
This adds cogl_texture_2d_sliced_new_from_bitmap/data/file apis in
preparation for removing the cogl_texture_new_from_bitmap/file apis that
are considered a bit too magic, but we don't want to loose the
convenience they have.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 218da8e1349d7658f45c6933b9736c0d32941b8b)
Conflicts:
cogl/cogl-auto-texture.c
This adds a cogl_texture_2d_new_from_file() api since we are planning to
remove cogl_texture_new_from_file() but don't want to loose the
convenience it had.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 10e91aa513123ed277a8d45976f8d75445d7dc9c)
This exposes the CoglAtlasTexture api, making the following public:
cogl_atlas_texture_new_with_size
cogl_atlas_texture_new_from_file
cogl_atlas_texture_new_from_data
cogl_atlas_texture_new_from_bitmap
The plan is to remove auto-texture apis like cogl_texture_new_from_file
since they are a bit too magic, but that means we need an explicit way
for users to allocate texture that will go in the atlas.
Although the _new_from_file() api is arguably redundant since you can
use _bitmap_new_from_file() followed by _atlas_texture_new_from_bitmap()
we don't want to loose any of the convenience that
cogl_texture_new_from_file() had.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit fe515e6063ba4c3ddb5cd00d2c8527d9a6336a12)
Conflicts:
cogl/Makefile.am
This removes the gl centric _cogl_texture_prepare_for_upload api from
cogl-texture.c and instead adds a _cogl_bitmap_convert_for_upload() api
which everything now uses instead. GL specific code that needed the gl
internal/format/type enums returned by _cogl_texture_prepare_for_upload
now use ->pixel_format_to_gl directly.
Since there was a special case optimization in
cogl_texture_new_from_file that aimed to avoid copying the temporary
bitmap that's created for the given file and allow conversions to
happen in-place the new _cogl_bitmap_convert_for_upload() api supports
converting in place depending on a 'can_convert_in_place' argument.
This ability to convert bitmaps in-place has been integrated across the
different components as appropriate.
In updating cogl-texture-2d-sliced.c this was able to remove a number of
other GL specific parts to how spans are setup.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e190dd23c655da34b9c5c263a9f6006dcc0413b0)
Conflicts:
cogl/cogl-auto-texture.c
cogl/cogl.symbols
cogl_display_new() takes a ref on the renderer, so code creating a
renderer and not keeping a pointer to it do unref later needs to drop
the ref immediately.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 5433555f19ac73f3f236026f1bafca758d63c9fa)
Just like:
commit f3adec1faeb651dd97095a02256932cc82761f40
Author: Neil Roberts <neil@linux.intel.com>
Date: Thu Jul 11 13:51:28 2013 +0100
Initialise dirty_real_blend_enable in _cogl_pipeline_copy
But this time for unknown_color_alpha.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e6a6a2752fb1cc14860cbc559f41f25f7e7f195e)
Mesa annotates the GL version string with "(Core Profile)" when using
the OpenGL 3 core profile and so our heuristics that try and determine
what vendor and GPU is being used where being confused. This updates
the check_mesa_driver_package() function to consider this optional
annotation.
This adds a small unit test to verify the parsing of some example
version strings. We can update this with more real world version strings
if the format changes again in the future.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 1a074173d20857c7bedb6a862958713e5ef8d2d1)
When making a copy of a pipeline, the flag to mark whether the real
blend enable is valid was not being initialised.
Thanks to Damien Lespiau for pointing this out
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f3adec1faeb651dd97095a02256932cc82761f40)
Instead of queuing the frame sync event immediately after a swap, the
Wayland winsys now installs a frame callback and queues the event when
Wayland reports that the frame is complete. It also reports the
COGL_FRAME_EVENT_COMPLETE event at the same time because there is no
more information we can give.
This patch is a bit of a divergence from how the events are handled in
the GLX winsys. Instead of installing its own idle function, the
_cogl_onscreen_queue_event() function has now been made non-static so
that it can be used by the Wayland winsys. The frame callback now just
queues an event using that. The pending_frame_infos queue on the
CoglOnscreen isn't used and instead the CoglFrameInfo is immediately
popped off the queue so that it can be stored as part of the closure
data when the frame callback is set up. That way it would use the
right frame info even if somehow the Wayland callbacks were invoked in
the wrong order and the code is a bit simpler.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f7ea370a0d5013c9f0263f37c7f892adc8a2f087)
Previously if the Wayland socket gets closed then Cogl would ignore
the error when dispatching events which meant the socket would be
constantly ready for reading, the main loop would never go idle and it
would sit at 100% CPU. When Wayland encounters an error it will
actually close the socket which means if something else opened another
file then we might even end up polling on a completely unrelated FD.
This patch makes it remove the FD from the main loop as soon as it
hits an error so that it will at least avoid breaking the main loop.
However I think most applications would probably want to abort in this
case so we might also want to add a way to inform the application of
this or even just abort directly.
The cogl_poll_* functions have been changed so that they can cope if
the pending and dispatch callbacks remove their own FD while they are
invoked.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 85857b10687a5a246a0a4ef42711e560c7a6f45d)
This allows to easily caculate shades of the same color or pick colors
with the same saturation/luminance. In short, all sorts of interesting
things.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit edcbeaf3c941f7a2335fbec47d5248cd9b0e8088)
This adds cogl_wayland_renderer_set_event_dispatch_enabled() which can
be used to prevent Cogl from adding the socket for the Wayland display
to its list of file descriptors to poll. This can be used in
applications that want to integrate Cogl with existing code that is
reading from the Wayland socket itself.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit f5b8d98676ab3e90ad80459019c737ec2ff90aa4)
