GLMemory input/output objects cannot be passed as mutable:
to_glib_none_mut checks if the miniobject is writable, even though the
underlying implementation should really only care about whether the
_data_ owned by this miniobject is.
(This temporary GLMemory object references its parent buffer object
that is also referenced externally, resulting in two references making
the object itself immutable)
Furthermore take care of automatically calling `add_rgba_pad_templates`
in `class_init` if `ADD_RGBA_PAD_TEMPLATES` is set to `true` (the
default).
Also enable all dependencies used by this type. Copying
AllocationParams is possible without borrowing the source mutable.
The offset and size parameters of `memcpy` are unchecked and may result
in out-of-bounds reads/writes, which is why this function is marked as
`unsafe`.
This class only contains two functions with a version requirement of at
least 1.16, but the class is used by GLFilter without any version
restrictions.
As collected with:
xmlstarlet sel -t -v "//_:field[@name = \"parent_class\"]/_:type/@name" gir-files/GstGL-1.0.gir | uniq
This adds GstBase.BaseTransform for GLBaseFilter and GLFilter, and
Gst.Element for gst::panic_to_error.
Similar to Rusts return and try, just use exceptions and pretty-print
them at the highest level (instead of presenting the user with a
stacktrace that's harder to read than the error alone).
Since the addition of doc regeneration - which also spawns a gir process
for every non-sys crate - the process is now incredibly slow and not
well suited for iterative development:
./generator.py --no-fmt 26.25s user 0.79s system 99% cpu 27.044 total
All gir processes are currently ran in serial (the generator waits for
one to complete before spawning the next process) even though there are
no inter-dependencies. Simply spawning all processes at once and
collecting their results + printing them in order after everything has
been spawned yields a significant speedup:
./generator.py --no-fmt 37.99s user 0.88s system 3285% cpu 1.183 total
Note: this is on a 32-core ThreadRipper. The improvement is more modest
on machines with less cores, and also depends on IO speed. A 4-core i5,
before and after:
./generator.py --no-fmt 30.24s user 0.76s system 99% cpu 31.055 total
./generator.py --no-fmt 57.78s user 0.88s system 763% cpu 7.685 total
That's still a sizable gain for simply not blocking on other tasks
anymore.
Since https://github.com/gtk-rs/gtk-rs/pull/447, supposedly the native
function is never returning a `NULL` `Application` hence it makes little
sense to handle an "unreachable" error here.
See https://github.com/gtk-rs/gtk-rs/pull/449. This struct remains
vital in GStreamer code to tie a type to an (untyped) SendValue, so that
the underlying value can be retrieved without having to guess its type.
That type is anyway stored in a private member T::TagType.
Co-authored-by: Marijn Suijten <marijns95@gmail.com>
Winit 0.19 uses uninitialized variables which is invalid since Rust
1.48, leading to a runtime panic [1]. Updating to the latest version
resolves these issues but requires significant refactoring since the
event loop now runs entirely within a closure.
[1]: https://github.com/rust-windowing/winit/issues/1811
If EGL and Wayland were both set the Wayland bit of code would never be
build-tested nor used. Now if both are enabled try to acquire a
GLDisplay through both handles before bailing. The methods can still be
tested in isolation by not enabling one or the other feature.
Solves the following warning:
gstreamer-rs/examples/Cargo.toml: unused manifest key: bin.31.features
Enabling features when a single bin is built is not supported, and users
would have to manually select desired features anyway: -wayland cannot
be used in conjunction with -egl thanks to the cfg_if.
Gir now prints all directories and their hashes in the version file and
comments; useful now that gstreamer-rs is being generated from both
gir-files/ and gst-gir-files/ submodules.
We were already using `gir -d` and especially now that our files are
separated across two directories that are relative to the directory
containing Gir.toml this only becomes cumbersome. Besides `gir` lacks
functionality to normalize the path, leading to ie.
gstreamer-gl/egl/sys/../../../gir-files in the version comment as a
result.
The sys crates have not been generated with 1.20 introspected gir files
yet, and break the documentation that is already compiling with the
v1_20 feature. Function body contents don't truly matter for the
documentation build anyway.