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
