gtk-rs / gdk-pixbuf

DEPRECATED, use https://github.com/gtk-rs/gtk-rs-core repository instead!

gdk-pixbuf

Gdk-Pixbuf bindings for Rust.

• Gtk-rs project site

• Online documentation

• Readme in our main repo

License

MIT

gdk-pixbuf's Issues

Implement gdk_pixbuf_copy/gdk_pixbuf_copy_options

https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-copy
and
https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-The-GdkPixbuf-Structure.html#gdk-pixbuf-copy-options

put_pixel can overflow arithmetic

Thread '' panicked at 'attempt to add with overflow', /home/usr-src-packages/BUILD/librsvg-2.46.4/vendor/gdk-pixbuf/src/pixbuf.rs:286:2

In reality it's the calculation of pos here:

gdk-pixbuf/src/pixbuf.rs

Line 274 in 3f0d965

let pos = (y * rowstride + x * n_channels) as usize;

#9  0x00007ffff55bf7ed in gdk_pixbuf::pixbuf::<impl gdk_pixbuf::auto::pixbuf::Pixbuf>::put_pixel (self=0x7ffffffece80, x=5912, y=25565, red=0, green=0, blue=0, alpha=0)
(gdb) p width
$15 = 21000
(gdb) p height
$16 = 29700
(gdb) p pixels
$17 = &mut [u8] {data_ptr: 0x7ffecaec5010 "\000", length: 2494800000}

All the values in the line that calculates pos are i32; I think we need to promote them to usize before doing arithmetic.

This is from https://gitlab.gnome.org/GNOME/librsvg/-/issues/584

Error while trying to load from pixbuf after scaling (mismatched types)

I'm trying to load images to a pixbuf and after that loading them into a GtkImage from Glade file, but I always get an error message during compile. Here I gave more details: https://stackoverflow.com/questions/60212129/rust-gtk-set-gtkimage-from-pixbuf-using-glade-file

add GDK_TYPE_PIXBUF

Necessary for use with gtk::ListStore::new(). Note that the G_TYPE_* variables have all been mapped to the nice gtk::type enum, so maybe there should be a gdk::Type::Pixbuf? I think this is the only type constant provided by gdk, but it'd be consistent.

Note that whatever the type of this constant ends up being, it'll need to be easily convertible to gtk::Type in order to be used with gtk::ListStore::new(&[gtk::Type]).

Missing Pixbuf::new_from_xpm_data

https://developer.gnome.org/gdk-pixbuf/stable/gdk-pixbuf-Image-Data-in-Memory.html#gdk-pixbuf-new-from-xpm-data

Can't find gdk_pixbuf::Pixbuf's rotate_simple() method

There's no mention of this essential method in the documentation and rustc can't find it either.

Status of new_from_data

I have image buffer data loaded using Rust std File. When looking for ways to create a new Pixbuf from that buffer data I found the new_from_data method that was commented. Where there issues implementing a binding? Any other reason why it hasn't been implemented?

gdk-pixbuf/src/auto/pixbuf.rs

Lines 72 to 74 in acbab23

	//pub fn new_from_data(data: &[u8], colorspace: Colorspace, has_alpha: bool, bits_per_sample: i32, width: i32, height: i32, rowstride: i32, destroy_fn: Option<Box_<dyn FnOnce(&Vec<u8>) + 'static>>) -> Pixbuf {
	// unsafe { TODO: call gdk_pixbuf_sys:gdk_pixbuf_new_from_data() }
	//}

Pixbuf::new_from_surface

Please, add support for function Gdk.pixbuf_get_from_surface(surface, src_x, src_y, width, height). As far as I know, it's the only way to render a pixbuf.

Request bindings for gdk_pixbuf_get_from_window() function be added to this crate

Availability of this function will enable the writing of programs that take screen snapshots.

E.g. use gdk::Window::get_default_root_window() to get the gdk::Window that represents the full screen and then use gdk_pixbuf_get_from_window(w, x, y, width, height) to get the pixbuf representing a portion of that window and then add it to the clipboard.

PixbufFormat requires &mut for all functions

@EPashkin Seems like a bug in GIR. There's no reason to require &mut for all the getters, and for the set_disabled() setter interior mutability as before seems better.

This is an API change btw

Loading Pixbuf non-blocking way

Loading Pixbufs in separate threads seem not to be possible. Gtk-rs documentation says that "calling any gtk or gdk functions (including init) from other threads will panic". It wouldn't be possible to Send Pixbufs between the threads anyway.

Also, gtk-rs doesn't support asynchronous I/O of glib.

Please, implement a mechanism to load Pixbuf without blocking the GTK main thread.

Can't find values to use for gdk_pixbuf::InterpType

gdk_pixbuf::InterpType used to be an enum with the possible values provided but has been replaced by a type definition as i32. However, I am now unable to determine the valid values for this type in the documentation. They are needed for methods such as simple_scale().

gdk::cairo_set_source_pixbuf

Function gdk::cairo_set_source_pixbuf(context, pixbuf, x, pixbuf_y) is missing. It's needed to draw a Pixbuf onto a surface.

new release?

Can you please release new version?
I want to use PixbufAnimation from_stream function, which is not in current latest build.

SVG support on Windows

I have followed this guide to crosscompile my GTK app to Windows, and everything seems to work fine, except that it doesn't recognize the SVG image format.

I tried also adding librsvg-2-2.dll, but that didn't seem to change anything. Any ideas what could be the problem?

Using gdk_pixbuf::Pixbuf::get_formats() returns these:
"ani" - "Windows animated cursor"
"png" - "PNG"
"bmp" - "BMP"
"gif" - "GIF"
"ico" - "Windows icon"
"jpeg" - "JPEG"
"pnm" - "PNM/PBM/PGM/PPM"
"tiff" - "TIFF"
"xpm" - "XPM"
"xbm" - "XBM"
"tga" - "Targa"
"icns" - "MacOS X icon"
"jpeg2000" - "JPEG 2000"
"qtif" - "QuickTime"

Pixbuf::put_pixel doesn't behave correctly when alpha channel is disabled

The current implementation always writes the alpha channel, no matter whether the alpha channel is enabled. When the alpha channel is disabled, the data will "leak" into adjacent pixels, and also cause an out-of-range error on the last pixel.
Simply don't write alpha when n_channels == 3 should solve the problem. #60

gdk_pixbuf_new() can return NULL on OOM

gdk_pixbuf_new() can return NULL if it cannot allocate memory for the pixel buffer. However, the binding's Pixbuf::new() does not contemplate this; it will probably crash in from_glib_full().

I think this needs an API break to return a Result 😞