| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
uninitialized memory
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/199
|
|
|
|
| |
Reference the anchor in the class description.
|
|
|
|
| |
Use proper summaries; remove gtk-doc'isms; document properties.
|
|
|
|
|
| |
Drop the gtk-doc SECTION markers, and move documentation to classes or
separate documents.
|
|
|
|
|
|
|
| |
The relative links in the functions documentation stanza refer to the
current section; this means that, in order to refer to an anchor
specified in a section the symbols must be in the same section within
the same file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If one does a plain
GdkPixbuf *pixbuf = g_object_new (GDK_TYPE_PIXBUF, NULL);
Then all the construct properties use their default values. This
means that both "pixels" and "pixel-bytes" get passed as NULL to
gdk_pixbuf_set_property().
Later, trying to get the property for "pixel-bytes" would assert,
incorrectly, because it was trying to create a GBytes from a NULL
pixels storage.
This commit adds a test for that construction case, and tests for
constructing with g_object_new() in general.
Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/91
|
|
|
|
|
|
|
|
|
| |
The read_pixels() method is missing a `Returns` stanza.
The read_pixels_bytes() method is missing a description.
Both functions do the same thing, so they should be documented
similarly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of checking the bytes vs. pixels fields all over the place, we
introduce an enum that says which mode the pixbuf is in. We have a
central downgrade_to_pixels() function to turn the pixbuf from
immutable to mutable.
This commit only does the gdk-pixbuf core; we'll deal with pixdata and
the loaders separately.
|
|
|
|
|
|
| |
gdk_pixbuf_composite_color_simple
https://bugzilla.gnome.org/show_bug.cgi?id=789935
|
|
|
|
|
|
|
| |
Calling g_bytes_unref_to_data() will copy the contents of the bytes
buffer, so we need to free the data.
https://bugzilla.gnome.org/show_bug.cgi?id=787626
|
|
|
|
|
|
| |
Reference links use "[title][id]" not "[title](id)", that's for URLs.
https://bugzilla.gnome.org/show_bug.cgi?id=765282
|
|
|
|
|
| |
Do not include the source, otherwise we're going to compile symbols
twice.
|
|
|
|
|
|
| |
To calculate the rowstride without allocating memory!
https://bugzilla.gnome.org/show_bug.cgi?id=765094
|
|
|
|
|
|
|
|
|
| |
The rowstride is stored as an int, and is an int in the public API.
Making it an unsigned int for those calculations would increase
the limit, which would obviously cause problems when the calculated
value ends up between G_MAXUINT and G_MAXINT in the positives.
https://bugzilla.gnome.org/show_bug.cgi?id=765094
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=143608
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The recommended way to do an overflow check is to check against the
limit you have in mind, rather than doing the calculation and seeing if
it failed.
Fix this by rearranging the check: move the variables we control (or
have previously checked) over to one side, leaving the unknown variable
on its own on the left-hand side. This ensures the overflow check
doesn’t overflow itself.
Coverity ID: 1388538
https://bugzilla.gnome.org/show_bug.cgi?id=777315
|
|
|
|
|
|
|
|
| |
Doing overflow checks with signed integers invokes undefined
behavior and induces modern compilers to omit the checks altogether.
Avoid this by doing the overflow check with unsigned integers.
https://bugzilla.gnome.org/show_bug.cgi?id=770986
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=768043
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=768043
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=768043
|
|
|
|
|
| |
We were emitting ::notify even for properties which have only
one possible value.
|
|
|
|
|
|
|
| |
This fixes a crash when using Python's "new" keyword instead of the
constructors exported by GdkPixbuf.
See https://bugzilla.gnome.org/show_bug.cgi?id=658702
|
|
|
|
|
| |
abicheck.sh threw an error because of the wrongly prefixed was used
in commit: f37f850abe714f19cd3d7e2d5e3bd93483d1ec8a
|
|
|
|
|
| |
Use glib's i18n support rather than copy pasting it. Note that
gdk_pixbuf_gettext() is kept as it's an exported symbol.
|
|
|
|
| |
As they're defined to the same thing anyway.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=466372
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=701622
|
| |
|
|
|
|
|
|
| |
gdk-pixbuf.c:663: Warning: GdkPixbuf: GObject-Introspection specific
GTK-Doc tag "Rename to" has been deprecated, please use annotations on
the identifier instead.
|
|
|
|
|
|
|
| |
So people don't have to guess the possible values of "key" in
gdk_pixbuf_get_option() calls
https://bugzilla.gnome.org/show_bug.cgi?id=674858
|
|
|
|
|
| |
Document the "multipage" option added in commit
09b3fc03284ac4f9a4f466ba908f9cd7309b2ced
|
|
|
|
|
|
|
|
| |
This can be convenient for language bindings to access the readonly
data in a form that includes length, and also avoids a copy (for
readonly pixbufs).
https://bugzilla.gnome.org/show_bug.cgi?id=732297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GdkPixbuf is an old API that predates introspection and GBytes. It
has some confusion around whether or not pixbuf data is mutable or
not. The _new_from_data() API takes a *const* pointer, but it's not
copied, and _get_pixels() returns a non-const copy of the same
pointer.
There are several cases where we get read-only data, such as a
GResource. For language bindings, _new_from_data() doesn't work
because the array may be a temporary copy only allocated for the call.
In order to support a clean _new_from_bytes() API, we need to add the
concept of a read-only pixbuf into the core. The fundamental hack
here is that _get_pixels() now causes an implicit copy.
For the cases where we don't want to copy, add a new
gdk_pixbuf_read_pixels() that returns a proper const pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=732297
|
|
|
|
|
| |
Switch to markdown for our inline markup needs, and
turn off sgml mode for the docs.
|
| |
|
|
|
|
| |
This lets us avoid some manual overflow checks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "new rules" for GIcon say that we must support serialisation via
g_icon_serialize() and loadability via GLoadableIcon, so implement both
of those.
Serialise GdkPixbuf by emitting a GVariant that will result in a
png-encoded GBytesIcon when deserialized. The GLoadableIcon interface
is similar: we return a stream that will read out as a png.
Test the serialisation by round-tripping an image through this process
and ensuring that it is pixel-perfect.
https://bugzilla.gnome.org/show_bug.cgi?id=688820
|
|
|
|
|
| |
Patch by Rafał Mużyło,
https://bugzilla.gnome.org/show_bug.cgi?id=676430
|
|
|
|
| |
Reported by Evan Nemerson in bug 659888.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Binary data needs an explicit length to be useful. Add a new API for
getting length of binary data, and allow gi users to use "get_pixels"
in a useful manner instead of just grabbing the first pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=662009
|
| |
|
|
|
|
|
|
|
| |
This puts all the docs that existed in tmpl files when
gdk-pixbuf was moved out of gtk into inline comments.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=635643
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=634059
|
| |
|
|
|
|
| |
This is copying similar changes from glib.
|
|
|
|
| |
Grudgingly, in the name of api stability.
|