While still leaving them unused, pass around ClutterPaintContext and
ClutterPickContext when painting and picking.
The reason for splitting this change up in two is to make it possible to
bisect easier in between the API change and the change to using the
framebuffer passed around with the temporary contexts.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/827
In `st`, we can do this by using `ST_PARAM_*`. In the other code files,
just use `G_PARAM_STATIC_STRINGS` directly.
This is just a minor convenience to prevent a few unnecessary string
copies.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/646
The same code for reading the current magnifier state is repeated in both
shell-recorder, shell-screenshot and magnifier itself.
So to move this inside a property of st-settings so that we can refer to it
all over the places removing duplications.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/473
Get from clutter the capture sizes and scale and don't mind
about doing any rounding here, as it might be different
from the one done at clutter level (causing mismatch and
not-working videos). Delegate this to clutter, and forget
about the internal details.
These values are then used to composte the image and set the video caps.
https://bugzilla.gnome.org/show_bug.cgi?id=7650111
Remove any usage of MetaScreen, as it has been removed from libmutter
in the API version 3. The corresponding functionality has been moved
into three different places: MetaDisplay, MetaX11Display (for X11
specific functionality) and MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Whenever a new cursor image is loaded also save it's hot x/y
coordinates. The drawing code already respects these values, however
they were never set. This change will place the cursor image at the
correct location as seen on screen. shell-screenshot.c served as
reference.
https://bugzilla.gnome.org/show_bug.cgi?id=792860
Mutter may capture the screen in multiple capture regions. If this is
done, take these images and composite them onto one large image, which
is then passed into the gstreamer source.
There is no longer any guarantee that there'll be one single
framebuffer to read pixels from. In order to still read pixels from the
stage, use the new clutter_stage_capture API.
https://bugzilla.gnome.org/show_bug.cgi?id=768979
When running as a wayland compositor, MetaCursorTracker might
legitimately not have a displayed cursor because e.g. a client unsets
the cursor surface.
Note that, under an X session, the assumption that the tracker always
has a cursor texture is true because XFixesGetCursorImage() always
returns data even if the cursor isn't visible.
https://bugzilla.gnome.org/show_bug.cgi?id=767001
Cut down on boilerplate by using the (no longer that) new helper
macros. We don't care about breaking ABI in private libraries, so
use G_DECLARE_FINAL_TYPE even where the class struct used to be
exposed in the header, except for types we inherit from ourselves
(obviously) or where the class exposes any vfuncs (where changes
could affect inheritance in extensions).
Currently we have been using the vp8 codec because it was the best unencumbered codec at that time. With vp9 we now have a successor that leads to smaller
files at at the same video quality and has been supported by current browsers
for a while.
With the raise of hidpi and 4K displays we need a better codec that handles
those resolutions better, so switch to vp9.
https://bugzilla.gnome.org/show_bug.cgi?id=742744
Send EOS to the complete pipeline instead of only to our own source.
When there are multiple sources in the pipeline (for example when we also
record audio), the pipeline will send the EOS to all sources in order to
shut down the complete pipeline.
Replace more direct XFixes usage with a the appropriate abstraction
API from mutter, which is guaranteed to work in wayland too.
It doesn't yet replace pointer position tracking, although probably
it should.
Also, because now we're using Mutter API, we lose the standalone
test case.
https://bugzilla.gnome.org/show_bug.cgi?id=705911
This will replace the indicator painted on the stage right now.
This unfortunately does not work for the recorder triggered by the
keybinding -- we'll simply replace the in-shell code with a keybinding
powered by gnome-settings-daemon.
The magnifier adds its own copy of the system cursor to apply the
expected transformations, so we don't need to add it again in the
recorder; this avoids two different cursors showing up in recordings,
but doesn't address the case where the cursor should not be recorded
at all, but the magnifier adds it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=700488
It looks a bit unpolished to overlap our own chrome with the recording
icon, which may happen when an existing adds UI at the bottom edge.
Fix this by using the primary monitor's workarea for the position rather
than the entire monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=700409
Currently we will always record the entire screen. It has been requested
to support recording a specified area analogous to the screenshot API as
well, so add a set_area() method which allows this.
https://bugzilla.gnome.org/show_bug.cgi?id=696247
It is currently not always possible to predict the actual output filename
of a recording - the file-template does not necessarily use an absolute
path and may contain %d and %t escape sequences.
This is OK for fire-and-forget uses like the existing keyboard shortcut,
but we will soon expose the functionality on DBus and consumers of that
API might very well need to access the file after the recording. So do
the same as our screenshot API and add an optional (out) parameter to
record().
https://bugzilla.gnome.org/show_bug.cgi?id=696247
Pointer tracking is broken when the pointer is over the stage input
area. This is apparently fallout from mutter going to XInput2.
This commit changes the mouse event handling code to also use XInput2.
https://bugzilla.gnome.org/show_bug.cgi?id=695324
The screen grabber was a workaround for an extremely slow path in Mesa
when reading back pixel data from the frame buffer. It was using pixel
buffer objects by directly calling into GL to hit a fast blit path in
Intel's driver. This should no longer be necessary with the latest
Mesa because the normal read pixels path now has a fast path to just
memcpy the data. Using PBOs in that case just adds an extra
indirection because the data is read into an intermediate buffer and
then copied back out again.
We want to be able to remove the dependency on linking against libGL
directly from Gnome Shell because that will not work if Cogl is
actually using GLES. Also libGL includes GLX which means gnome-shell
ends up with a hard dependency on Xlib which hinders the goal of
getting Gnome Shell to be a Wayland compositor.
https://bugs.freedesktop.org/show_bug.cgi?id=46631https://bugzilla.gnome.org/show_bug.cgi?id=685915
Often the first thing a user wants to do after making a recording
is post it somewhere.
This commit adds the video to recently used items, so that it shows
up prominently in open file choosers.
https://bugzilla.gnome.org/show_bug.cgi?id=680647
