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
We want to make sure the recorder isn't finalized until the
saved recording hits disk. This means the pipeline object needs
a hard reference on the recorder.
https://bugzilla.gnome.org/show_bug.cgi?id=680647
The speed and quality properties have been removed in favor of properties
closer to the upstream library.
Removing the properies from the pipeline would result into a huge
slowdown so we have to map the old values to the new ones.
According to the source code of the old vp8enc element quality maps to
(int)(63 - quality * 6.2) for min_quantizer and max_quantizer, while
speed maps to cpu-used = speed == 0 ? 0 : (speed - 1).
So set min_quantizer and min_quantizer to 13, and cpu-used to 5 based on
the above formulas.
https://bugzilla.gnome.org/show_bug.cgi?id=684206
The default filename isn't localized and isn't the same one that
the shell sets. Just remove the fallback mechanism, and abort
recording if somebody didn't set the filename
https://bugzilla.gnome.org/show_bug.cgi?id=677434
Instead of adding every rendered frame into the recording, drop frames
and only buffer and record enough frames to match the target framerate.
Increase the default frame rate from 15 to 30, since now that we're
actually enforcing framerate, it's noticeable that 15fps is not smooth.
https://bugzilla.gnome.org/show_bug.cgi?id=669066
The default pipeline was fairly aggressive about quality, and could
be too expensive for some computers. Decrease the quality setting for
the vp8 codec from 10 to 8, and increase the speed setting from 2 to 6.
(Basically, quality affects the visual fidelity of the end result, while
speed affects how much CPU the encoder uses to get a high compression
ratio at that quality level.)
Remove videorate from the pipeline, since the GStreamer VP8 encoder can
handle variable-framerate streams. This means that we won't spend CPU
encoding duplicate frames added by videorate.
https://bugzilla.gnome.org/show_bug.cgi?id=669066
For the Intel drivers, using glReadPixels() to read into client-memory
directly from the frame buffer is much slower than creating a pixel
buffer, copying into that, and then mapping that for reading. On other
drivers, the two approaches are likely to be similar in speed. Create
a ShellScreenGrabber abstraction that uses pixel buffers if available.
Use that for screenshots and screen recording.
https://bugzilla.gnome.org/show_bug.cgi?id=669065
Clutter 1.7.x introduced CLUTTER_CAIRO_FORMAT_ARGB32: which can be used when
sharing textures/data with cairo without having to do check the
byte order and choose the appropriate format by hand.
https://bugzilla.gnome.org/show_bug.cgi?id=654577
cogl_read_pixels() used to only support a useless pixel format, but it
will do our preferred format now, so use it rather than doing GL stuff
by hand.
https://bugzilla.gnome.org/show_bug.cgi?id=648758
The vp8 codec provides better performance in pretty much all cases compared
to theora while still being free (as in not patent encumbered).
Also add a %T placeholder to the pipeline string which will be replaced
with the a thread count based on the target system.
https://bugzilla.gnome.org/show_bug.cgi?id=632595
- Specify a minimum version of clutter-1.2.0
- Switch clutter branch in the moduleset to master
- Replace deprecated cogl_texture/material_unref() with
cogl_handle_unref()
- Use cogl_clip_push_rectangle() rather than cogl_clip_push()
- Replace cogl_check_extension() with strstr - should be
accurate enough.
https://bugzilla.gnome.org/show_bug.cgi?id=610679
Make the framerate, file extension and gstreamer pipeline used by the
screencast recorder configureable using gconf.
This patch does not change the defaults, it justs provides a way for
the user to override them.
https://bugzilla.gnome.org/show_bug.cgi?id=608995
The screen recording wasn't working because of two bad interactions
with Cogl:
- Buffered primitives weren't being flushed out
- Cogl changes the pixel store values away from their default values
Thanks for Jon Nettleton for tracking down the source of the
problems with the recorder.
https://bugzilla.gnome.org/show_bug.cgi?id=598390
Some C library versions have __attribute__((warn_unused_result)) on
fgets(). We really don't care since we are just throwing the data
away, but check the result anyways.
