Re: An alternative to gdk-pixbuf
On Tue, 11 Sep 2018 00:07:27 +0200 Bastien Nocera wrote: > On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote: > > On Mon, 10 Sep 2018 11:31:42 +0200 > > Bastien Nocera wrote: > > > > I do use a library (or two). I've written one plugin that uses > > giflib and one that uses ImageMagick. I assumed using giflib would > > be a straighter path, but it wasn't. Firstly it only supports > > reading images > > from disk (but abydos automatically creates temporary files then > > needed > > so that didn't add any extra code at least). Secondly it doesn't do > > much more than unpacking the pixels. How to interpret what comes out > > is > > left as an exercise for the user, and requires a bit of knowledge > > about > > the GIF formats and it's quirks. So that plugin isn't built by > > default. > > ImageMagick on the other hand did much more to be of help, and > > required > > far less code to use. So shifting the responsibility to ImageMagick > > seems reasonable, I think. > > No, it really isn't: > https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html > > We want to have less CVEs, not more. I see what you mean. A few of them (although none of the more serious ones) were even related to the GIF loader specifically. But the sheer volume kind of speaks for itself otherwise. :( > > I tested them both on all the GIF images included in the gdk-pixbuf > > test suit. Both plugins mostly work, but to varying degree. The one > > based on giflib segfaults with 1_partyanimsm2.gif (because the > > allocation containing the pixels which giflib provides is less than > > the > > images width x height, I haven't yet looked deeper into it). The > > ImageMagick based plugin on the other doesn't crash at least, and > > all the invalid images are correctly classified as invalid. The > > image 1_partyanimsm2.gif still shows as garbage except the first > > frame. The image aero.gif has the frame delay set to zero for every > > frame but the > > first. I'm not sure how that should be interpreted, so I simply > > exchanged zero values for a small delay (0.02 seconds). I will read > > up > > on the GIF format and hopefully get things working better. > > > > It's available here if you want to try it out: > > http://snisurset.net/code/abydos/ > > Having looked at giflib, and knowing the author, the current plan > still is to have something based on libnsgif in the future. I guess I'll write a third GIF plugin based libnsgif then. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: An alternative to gdk-pixbuf
On Mon, 2018-09-10 at 22:29 +0200, Magnus Bergman wrote: > On Mon, 10 Sep 2018 11:31:42 +0200 > Bastien Nocera wrote: > > > > I've written loader for GIF that simply wraps abydos. In lines of > > > code it's about a quarter the size of the current loader, even > > > including > > > the GIF plugin for abydos. It might even be slightly smaller with > > > the whole of abydos included in the equation. On the downside it > > > probably doesn't pass the test suite since I haven't tried it. > > > But > > > I will, and hopefully publish the whole thing in a couple of > > > days. > > > > That's unfortunately not mergeable, and unless you use a library > > for > > your GIF plugin in abydos, would just be shifting the potential > > bugs > > to the abydos code base. > > I do use a library (or two). I've written one plugin that uses giflib > and one that uses ImageMagick. I assumed using giflib would be a > straighter path, but it wasn't. Firstly it only supports reading > images > from disk (but abydos automatically creates temporary files then > needed > so that didn't add any extra code at least). Secondly it doesn't do > much more than unpacking the pixels. How to interpret what comes out > is > left as an exercise for the user, and requires a bit of knowledge > about > the GIF formats and it's quirks. So that plugin isn't built by > default. > ImageMagick on the other hand did much more to be of help, and > required > far less code to use. So shifting the responsibility to ImageMagick > seems reasonable, I think. No, it really isn't: https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html We want to have less CVEs, not more. > I tested them both on all the GIF images included in the gdk-pixbuf > test suit. Both plugins mostly work, but to varying degree. The one > based on giflib segfaults with 1_partyanimsm2.gif (because the > allocation containing the pixels which giflib provides is less than > the > images width x height, I haven't yet looked deeper into it). The > ImageMagick based plugin on the other doesn't crash at least, and all > the invalid images are correctly classified as invalid. The image > 1_partyanimsm2.gif still shows as garbage except the first frame. The > image aero.gif has the frame delay set to zero for every frame but > the > first. I'm not sure how that should be interpreted, so I simply > exchanged zero values for a small delay (0.02 seconds). I will read > up > on the GIF format and hopefully get things working better. > > It's available here if you want to try it out: > http://snisurset.net/code/abydos/ Having looked at giflib, and knowing the author, the current plan still is to have something based on libnsgif in the future. > > > > - we disable every loader by default except the ones that the > > > > core > > > > desktop needs > > > > - image viewers that rely on gdk-pixbuf ship their additional > > > > loaders > > > > in the app's Flatpak[1]. > > > > > > I don't care much for Flatpak in particular. But generalised and > > > rephrased as, leave it to the distributors to decide, I agree > > > that > > > this is absolutely the best approach. > > > > Without Flatpak, you're just removing image format support from > > image > > viewers, as many packaging guidelines in distributions forbid the > > bundling of libraries. They'd want to ship a single copy of the > > gdk- > > pixbuf loaders, and the applications wouldn't have any protection > > from > > files that the loaders would trip over. > > I'm not arguing against that. I just think it's an issue best left > entirely to distributors (including the choice between bundling and > dependencies). > > How and where to implement sandboxing is an interesting question > still. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: "draw" icon with string
Dear cecashon,
thanks for your code. This works currently.
I need to improve it in the future to support different plattforms
(fonts) and screen resolutions (scale).
kind
Christian
On 2018-09-10 19:32
wrote:
>
> Give this a try. It creates a surface, draws on it and then returns
> the surface so that it can be put in an image widget.
>
>
> import gi
> gi.require_version('Gtk', '3.0')
> from gi.repository import Gtk, Gdk
> import cairo
>
> class MainWindow(Gtk.Window):
> def __init__(self):
> Gtk.Window.__init__(self)
> self.set_title("Surface")
> self.set_default_size(400, 400)
> self.set_position(Gtk.WindowPosition.CENTER)
>
> surface = self.get_surface()
>
> image = Gtk.Image()
> image.set_from_surface(surface)
> image.set_vexpand(True)
> image.set_hexpand(True)
>
> grid = Gtk.Grid()
> grid.attach(image, 0, 0, 1, 1)
> self.add(grid)
>
> def get_surface(self):
> surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 200, 200)
> cr = cairo.Context(surface)
>
> cr.set_source_rgb(0.8, 0.8, 0.8)
> cr.paint()
>
> cr.set_source_rgb(0.0, 1.0, 0.0)
> cr.set_line_width(6)
> cr.rectangle(0, 0, 200.0, 200.0)
> cr.stroke()
> cr.set_source_rgb(0.0, 0.0, 1.0)
> cr.set_line_width(3)
> cr.move_to(0.0, 100.0)
> cr.line_to(200.0, 100.0)
> cr.stroke()
> cr.move_to(100.0, 0.0)
> cr.line_to(100.0, 200.0)
> cr.stroke()
>
> cr.set_source_rgb(1.0, 0.0, 1.0)
> cr.select_font_face("Arial", cairo.FONT_SLANT_NORMAL,
> cairo.FONT_WEIGHT_BOLD) cr.set_font_size(40)
> (x, y, width, height, dx, dy) = cr.text_extents("Cairo")
> cr.move_to(200/2 - width/2, 200/2 + height/2)
> cr.show_text("Cairo")
>
> cr.set_source_rgb(0.0, 0.0, 0.0)
> cr.set_line_width(1)
> cr.rectangle(200/2-width/2, 200/2 - height/2, width, height)
> cr.stroke()
>
> return surface
>
> win = MainWindow()
> win.connect("delete-event", Gtk.main_quit)
> win.show_all()
> Gtk.main()
>
>
>
> -Original Message-
> From: c.buhtz--- via gtk-app-devel-list
> To: c.buhtz--- via gtk-app-devel-list
> Cc: c.buhtz
> Sent: Sun, Sep 9, 2018 2:14 pm
> Subject: Re: "draw" icon with string
>
> On 2018-09-09 23:01 "c.buhtz--- via gtk-app-devel-list"
> wrote:
> > It is unclear to me how to create a cairo.Surface instance.
> >
> >
>
> And I can not see any text/string drawing methods in the surface
> class. ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: "draw" icon with string
Have you seen the recent post from Eric Cashon? I think it's a similar
example but in Python. Sorry, but I've never used Pycairo.
On 10/09/18 16:53, c.buhtz--- via gtk-app-devel-list wrote:
Thanks Chris for your example code.
But I am not able to map your C code to Pycairo.
Even the doc of Pycairo is not helpfull. No examples, no class trees.
I still don't know how to draw text to a cairo surface. It is also
unclear to me which surface I should use.
On 2018-09-09 18:22 Chris Moller wrote:
Here's a sample I came across some time ago.. Basically, you need to
do all the drawing using cairo primitives.
/*
Test drawing on a toggle button.
gcc -Wall cairobutton.c -o cairobutton `pkg-config --cflags
--libs gtk+-3.0`
C. Eric Cashon
*/
#include
gboolean
draw_button1 (GtkWidget *widget, cairo_t *cr, gpointer user_data)
{
guint width = gtk_widget_get_allocated_width(GTK_WIDGET(widget));
guint height = gtk_widget_get_allocated_height(GTK_WIDGET(widget));
if (gtk_toggle_button_get_active(GTK_TOGGLE_BUTTON(widget))) {
cairo_set_source_rgb (cr, 1.0, 0.0, 0.0);
cairo_paint (cr);
}
else {
cairo_set_source_rgb (cr, 0.1, 0.1, 0.1);
cairo_paint (cr);
}
//Draw rectangle around the button.
cairo_set_line_width (cr, 10.0);
cairo_set_source_rgb (cr, 0.0, 0.0, 0.0);
cairo_rectangle (cr, 0, 0, width, height);
cairo_stroke (cr);
//Add the text.
cairo_set_source_rgb (cr, 1.0, 1.0, 0.0);
cairo_text_extents_t extents;
cairo_select_font_face (cr, "Courier", CAIRO_FONT_SLANT_NORMAL,
CAIRO_FONT_WEIGHT_BOLD);
cairo_set_font_size (cr, 20);
cairo_text_extents (cr, "Cairo Toggle!", );
cairo_move_to (cr, width/2 - extents.width/2, height/2 +
extents.height/2);
cairo_show_text (cr, "Cairo Toggle!");
return TRUE;
}
int
main (int argc, char **argv)
{
gtk_init (, );
GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_position (GTK_WINDOW(window), GTK_WIN_POS_CENTER);
gtk_window_set_default_size (GTK_WINDOW (window), 200, 100);
gtk_window_set_title (GTK_WINDOW (window), "Toggle Button");
g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit),
NULL);
GtkWidget *button1 = gtk_toggle_button_new ();
gtk_widget_set_app_paintable (button1, TRUE);
gtk_widget_set_hexpand (button1, TRUE);
gtk_widget_set_vexpand (button1, TRUE);
g_signal_connect (button1, "draw", G_CALLBACK (draw_button1),
NULL);
GtkWidget *grid = gtk_grid_new ();
gtk_container_set_border_width (GTK_CONTAINER (grid), 10);
gtk_grid_attach (GTK_GRID (grid), button1, 0, 0, 1, 1);
gtk_container_add (GTK_CONTAINER (window), grid);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
On 09/09/18 17:14, c.buhtz--- via gtk-app-devel-list wrote:
On 2018-09-09 23:01 "c.buhtz--- via gtk-app-devel-list"
wrote:
It is unclear to me how to create a cairo.Surface instance.
And I can not see any text/string drawing methods in the surface
class. ___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Cancel a Drag & Drop for some specific items in a Gtk.TreeView
I also opened this question on https://stackoverflow.com/q/51974845/4865723 I have a Gtk.TreeView here. Most but not all of the items should be able to be dragged & dropped. For example the first item should not be able to be dragged & dropped but it should be selectable. How can I realize this? Maybe I have to use the drag-begin signal and stop the drag in there. But I don't know how. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: "draw" icon with string
Thanks Chris for your example code.
But I am not able to map your C code to Pycairo.
Even the doc of Pycairo is not helpfull. No examples, no class trees.
I still don't know how to draw text to a cairo surface. It is also
unclear to me which surface I should use.
On 2018-09-09 18:22 Chris Moller wrote:
> Here's a sample I came across some time ago.. Basically, you need to
> do all the drawing using cairo primitives.
>
>
> /*
> Test drawing on a toggle button.
>
> gcc -Wall cairobutton.c -o cairobutton `pkg-config --cflags
> --libs gtk+-3.0`
>
> C. Eric Cashon
> */
>
> #include
>
> gboolean
> draw_button1 (GtkWidget *widget, cairo_t *cr, gpointer user_data)
> {
> guint width = gtk_widget_get_allocated_width(GTK_WIDGET(widget));
> guint height = gtk_widget_get_allocated_height(GTK_WIDGET(widget));
>
> if (gtk_toggle_button_get_active(GTK_TOGGLE_BUTTON(widget))) {
> cairo_set_source_rgb (cr, 1.0, 0.0, 0.0);
> cairo_paint (cr);
> }
> else {
> cairo_set_source_rgb (cr, 0.1, 0.1, 0.1);
> cairo_paint (cr);
> }
>
> //Draw rectangle around the button.
> cairo_set_line_width (cr, 10.0);
> cairo_set_source_rgb (cr, 0.0, 0.0, 0.0);
> cairo_rectangle (cr, 0, 0, width, height);
> cairo_stroke (cr);
>
> //Add the text.
> cairo_set_source_rgb (cr, 1.0, 1.0, 0.0);
> cairo_text_extents_t extents;
> cairo_select_font_face (cr, "Courier", CAIRO_FONT_SLANT_NORMAL,
> CAIRO_FONT_WEIGHT_BOLD);
> cairo_set_font_size (cr, 20);
> cairo_text_extents (cr, "Cairo Toggle!", );
> cairo_move_to (cr, width/2 - extents.width/2, height/2 +
> extents.height/2);
> cairo_show_text (cr, "Cairo Toggle!");
>
> return TRUE;
> }
>
> int
> main (int argc, char **argv)
> {
> gtk_init (, );
>
> GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> gtk_window_set_position (GTK_WINDOW(window), GTK_WIN_POS_CENTER);
> gtk_window_set_default_size (GTK_WINDOW (window), 200, 100);
> gtk_window_set_title (GTK_WINDOW (window), "Toggle Button");
> g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit),
> NULL);
>
> GtkWidget *button1 = gtk_toggle_button_new ();
> gtk_widget_set_app_paintable (button1, TRUE);
> gtk_widget_set_hexpand (button1, TRUE);
> gtk_widget_set_vexpand (button1, TRUE);
> g_signal_connect (button1, "draw", G_CALLBACK (draw_button1),
> NULL);
>
> GtkWidget *grid = gtk_grid_new ();
> gtk_container_set_border_width (GTK_CONTAINER (grid), 10);
> gtk_grid_attach (GTK_GRID (grid), button1, 0, 0, 1, 1);
>
> gtk_container_add (GTK_CONTAINER (window), grid);
>
> gtk_widget_show_all (window);
> gtk_main ();
> return 0;
> }
>
>
> On 09/09/18 17:14, c.buhtz--- via gtk-app-devel-list wrote:
> > On 2018-09-09 23:01 "c.buhtz--- via gtk-app-devel-list"
> > wrote:
> >> It is unclear to me how to create a cairo.Surface instance.
> >>
> >>
> > And I can not see any text/string drawing methods in the surface
> > class. ___
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >
> >
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An alternative to gdk-pixbuf
On Mon, 10 Sep 2018 07:02:23 + Debarshi Ray wrote: > On Sun, Sep 09, 2018 at 02:57:30AM +0200, Magnus Bergman wrote: > > Many fields of science deal with images of multi > > gigabyte sizes. Ideally any image viewer should be able to handle > > these too with the right plugin (probably using GEGL in that case). > > But I think the problem with large images (say 12000x12000 or so) > > is giving it to the application as a pixmap. From my own tests it > > seams it's fine at least as long as the images are no bigger than > > the screen. So if the drawing (and implicitly also scaling) is > > handed over to the loading library (which in turn might hand it > > over to the plugin), this problem can be avoided. > > Even if one does decode the entire full resolution image into a tiled > data structure (say, GeglBuffer), there's no need to create a Cairo > surface for the entire image at 1:1 zoom. All that's needed is a > surface to represent the visible area at the visible zoom. That's a > lot more manageable. Yes, exactly. Using abydos_render() that's very possible to implement by the back end. Then trying to view larger images using gdk-pixbuf, I didn't experience any particular problems then the image was at normal size or zoomed in. The problem was zooming out. So I think just creating one or two prescaled versions will get you quite far (as long as there is no problem fitting the image into memory that is). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: An alternative to gdk-pixbuf
On Mon, 10 Sep 2018 11:31:42 +0200 Bastien Nocera wrote: > > I've written loader for GIF that simply wraps abydos. In lines of > > code it's about a quarter the size of the current loader, even > > including > > the GIF plugin for abydos. It might even be slightly smaller with > > the whole of abydos included in the equation. On the downside it > > probably doesn't pass the test suite since I haven't tried it. But > > I will, and hopefully publish the whole thing in a couple of days. > > That's unfortunately not mergeable, and unless you use a library for > your GIF plugin in abydos, would just be shifting the potential bugs > to the abydos code base. I do use a library (or two). I've written one plugin that uses giflib and one that uses ImageMagick. I assumed using giflib would be a straighter path, but it wasn't. Firstly it only supports reading images from disk (but abydos automatically creates temporary files then needed so that didn't add any extra code at least). Secondly it doesn't do much more than unpacking the pixels. How to interpret what comes out is left as an exercise for the user, and requires a bit of knowledge about the GIF formats and it's quirks. So that plugin isn't built by default. ImageMagick on the other hand did much more to be of help, and required far less code to use. So shifting the responsibility to ImageMagick seems reasonable, I think. I tested them both on all the GIF images included in the gdk-pixbuf test suit. Both plugins mostly work, but to varying degree. The one based on giflib segfaults with 1_partyanimsm2.gif (because the allocation containing the pixels which giflib provides is less than the images width x height, I haven't yet looked deeper into it). The ImageMagick based plugin on the other doesn't crash at least, and all the invalid images are correctly classified as invalid. The image 1_partyanimsm2.gif still shows as garbage except the first frame. The image aero.gif has the frame delay set to zero for every frame but the first. I'm not sure how that should be interpreted, so I simply exchanged zero values for a small delay (0.02 seconds). I will read up on the GIF format and hopefully get things working better. It's available here if you want to try it out: http://snisurset.net/code/abydos/ > > > - we disable every loader by default except the ones that the core > > > desktop needs > > > - image viewers that rely on gdk-pixbuf ship their additional > > > loaders > > > in the app's Flatpak[1]. > > > > I don't care much for Flatpak in particular. But generalised and > > rephrased as, leave it to the distributors to decide, I agree that > > this is absolutely the best approach. > > Without Flatpak, you're just removing image format support from image > viewers, as many packaging guidelines in distributions forbid the > bundling of libraries. They'd want to ship a single copy of the gdk- > pixbuf loaders, and the applications wouldn't have any protection from > files that the loaders would trip over. I'm not arguing against that. I just think it's an issue best left entirely to distributors (including the choice between bundling and dependencies). How and where to implement sandboxing is an interesting question still. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: "draw" icon with string
Give this a try. It creates a surface, draws on it and then returns the surface
so that it can be put in an image widget.
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk, Gdk
import cairo
class MainWindow(Gtk.Window):
def __init__(self):
Gtk.Window.__init__(self)
self.set_title("Surface")
self.set_default_size(400, 400)
self.set_position(Gtk.WindowPosition.CENTER)
surface = self.get_surface()
image = Gtk.Image()
image.set_from_surface(surface)
image.set_vexpand(True)
image.set_hexpand(True)
grid = Gtk.Grid()
grid.attach(image, 0, 0, 1, 1)
self.add(grid)
def get_surface(self):
surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 200, 200)
cr = cairo.Context(surface)
cr.set_source_rgb(0.8, 0.8, 0.8)
cr.paint()
cr.set_source_rgb(0.0, 1.0, 0.0)
cr.set_line_width(6)
cr.rectangle(0, 0, 200.0, 200.0)
cr.stroke()
cr.set_source_rgb(0.0, 0.0, 1.0)
cr.set_line_width(3)
cr.move_to(0.0, 100.0)
cr.line_to(200.0, 100.0)
cr.stroke()
cr.move_to(100.0, 0.0)
cr.line_to(100.0, 200.0)
cr.stroke()
cr.set_source_rgb(1.0, 0.0, 1.0)
cr.select_font_face("Arial", cairo.FONT_SLANT_NORMAL,
cairo.FONT_WEIGHT_BOLD)
cr.set_font_size(40)
(x, y, width, height, dx, dy) = cr.text_extents("Cairo")
cr.move_to(200/2 - width/2, 200/2 + height/2)
cr.show_text("Cairo")
cr.set_source_rgb(0.0, 0.0, 0.0)
cr.set_line_width(1)
cr.rectangle(200/2-width/2, 200/2 - height/2, width, height)
cr.stroke()
return surface
win = MainWindow()
win.connect("delete-event", Gtk.main_quit)
win.show_all()
Gtk.main()
-Original Message-
From: c.buhtz--- via gtk-app-devel-list
To: c.buhtz--- via gtk-app-devel-list
Cc: c.buhtz
Sent: Sun, Sep 9, 2018 2:14 pm
Subject: Re: "draw" icon with string
On 2018-09-09 23:01 "c.buhtz--- via gtk-app-devel-list"
wrote:
> It is unclear to me how to create a cairo.Surface instance.
>
And I can not see any text/string drawing methods in the surface class.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: An alternative to gdk-pixbuf
On Sun, 2018-09-09 at 01:23 +0200, Magnus Bergman wrote: > On Fri, 07 Sep 2018 12:51:32 +0200 > Bastien Nocera wrote: > > > > > Gegl is great for image editing. But not as much for simple > > > > viewing. > > > > > > This is debatable. If I'm viewing a 4000x4000 RGB image on a > > > hidpi > > > display I'm already pushing gdk-pixbuf and cairo to their limits > > > because of the scaling factor applied to the window — not only > > > the > > > buffer gets loaded uncompressed to allow for zooming, but the > > > image > > > viewer needs to render a CPU-scaled down copy of the image. > > > > > > Sure, for viewing a 500x400px image macro for a meme we're fine; > > > but > > > we're fine with gdk-pixbuf as well, so there's really no need to > > > change to a different image loading library. > > > > I concur, 4000x4000 would likely OOM your machine, and it's not > > really > > fixable: > > https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/30 > > > > Viewers should use GEGL, and GEGL should be taught about more > > formats. > > That still leaves many GIF files unhandled though, and I'm not sure > > we'd want apps writing their own GIF loader, seeing how complicated > > that is. > > How do you mean it's not fixable? Of course it's not fixable that > processing larger amounts of data will require more processing power. > So I think it's kind of obvious that creating thumbnails for many > large > images will take it's time. But that shouldn't need be too much of a > problem. Without looking too deeply into it, it looks like a problem > with nautilus to me. Obviously it's a bad idea to to run the > thumbnailers synchronously (which I can't imagine Nautilus does), and > it's also bad to run too many memory hungry tasks in parallel. But > that must be fixable, right? Like limiting the the total size in > bytes > of files being allowed to be processed in parallel, for example. It's not fixable without breaking the API and ABI of gdk-pixbuf. And nautilus doesn't thumbnail images itself (there's a thumbnailer that gets sandboxed by the thumbnailing code), or do it synchronously (the thumbnailers are out-of-process). > > > The animation API is pretty much a garbage fire, so it may go on > > > the chopping block as well. Of course, deprecated API will keep > > > working as well—or as badly—as it works today, so people can > > > still > > > use it. Moving pixbuf loaders to separate processes, and wrap > > > them > > > in sandboxes, would be a fairly good thing to do; it need to be > > > decided at run time, though, because there are many users of > > > GdkPixbuf that already run in a sandbox, which prevents creating > > > smaller sandboxes inside it. > > > > That'd be best left to an API that can do that natively, with the > > API > > being thought out ahead of time. > > > > In the short term, my wishlist/TODO list would be: > > - somebody writes a GIF loader that is readable, and passes the > > test > > suite. > > I've written loader for GIF that simply wraps abydos. In lines of > code it's about a quarter the size of the current loader, even > including > the GIF plugin for abydos. It might even be slightly smaller with the > whole of abydos included in the equation. On the downside it probably > doesn't pass the test suite since I haven't tried it. But I will, and > hopefully publish the whole thing in a couple of days. That's unfortunately not mergeable, and unless you use a library for your GIF plugin in abydos, would just be shifting the potential bugs to the abydos code base. > > - we disable every loader by default except the ones that the core > > desktop needs > > - image viewers that rely on gdk-pixbuf ship their additional > > loaders > > in the app's Flatpak[1]. > > I don't care much for Flatpak in particular. But generalised and > rephrased as, leave it to the distributors to decide, I agree that > this is absolutely the best approach. Without Flatpak, you're just removing image format support from image viewers, as many packaging guidelines in distributions forbid the bundling of libraries. They'd want to ship a single copy of the gdk- pixbuf loaders, and the applications wouldn't have any protection from files that the loaders would trip over. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: An alternative to gdk-pixbuf
On Mon, Sep 10, 2018 at 09:40:13AM +0100, jcup...@gmail.com wrote: > I make a gtk viewer that can display large images efficiently (over > 100,000 x 100,000), linked above. I hit a few other issues: > > 1. You can't use a large ScrolledWindow and only paint the visible > area, since you can easily go over the 64k pixel limit on viewports. > You have to handle all the scrolling yourself. Yes, the View widget needs to implement GtkScrollable, and not be one massive GtkDrawingArea. > 2. You need to keep all image processing in a set of background > threads and update the display asynchronously, perhaps this is > obvious. I thought we were talking about a "simple" viewer. :) Yes, if you are doing any kind of image processing, you can't let that block the UI. But if you are just talking about zooming in and out, then a gegl_buffer_get() inside GtkWidget::draw isn't terrible. There are 8 mipmap levels, so your 100,000 x 100,000 image becomes 12500 x 12500. > 3. You have to do the double-buffering yourself as well, since it can > take a while to generate a new view and you have to update the screen > as new chunks of image are generated. You don't need double-buffering if you want to update the View as soon as new chunks are generated. That's what GIMP does. You'll need it if you want to update the entire view in one frame. Here's a standalone widget to render a GeglNode that supports animated zooms and double-buffered updates: https://gitlab.gnome.org/GNOME/gnome-photos/blob/master/src/photos-image-view.c There's also gegl-gtk, but it might be a little dusty. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: An alternative to gdk-pixbuf
On Mon, 10 Sep 2018 at 08:02, Debarshi Ray wrote: > > too with the right plugin (probably using GEGL in that case). But I > > think the problem with large images (say 12000x12000 or so) is giving > > it to the application as a pixmap. From my own tests it seams it's fine > > at least as long as the images are no bigger than the screen. So if the > > drawing (and implicitly also scaling) is handed over to the loading > > library (which in turn might hand it over to the plugin), this problem > > can be avoided. > > Even if one does decode the entire full resolution image into a tiled > data structure (say, GeglBuffer), there's no need to create a Cairo > surface for the entire image at 1:1 zoom. All that's needed is a > surface to represent the visible area at the visible zoom. That's a > lot more manageable. I make a gtk viewer that can display large images efficiently (over 100,000 x 100,000), linked above. I hit a few other issues: 1. You can't use a large ScrolledWindow and only paint the visible area, since you can easily go over the 64k pixel limit on viewports. You have to handle all the scrolling yourself. 2. You need to keep all image processing in a set of background threads and update the display asynchronously, perhaps this is obvious. 3. You have to do the double-buffering yourself as well, since it can take a while to generate a new view and you have to update the screen as new chunks of image are generated. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: An alternative to gdk-pixbuf
On Sun, Sep 09, 2018 at 02:57:30AM +0200, Magnus Bergman wrote: > Many fields of science deal with images of multi > gigabyte sizes. Ideally any image viewer should be able to handle these > too with the right plugin (probably using GEGL in that case). But I > think the problem with large images (say 12000x12000 or so) is giving > it to the application as a pixmap. From my own tests it seams it's fine > at least as long as the images are no bigger than the screen. So if the > drawing (and implicitly also scaling) is handed over to the loading > library (which in turn might hand it over to the plugin), this problem > can be avoided. Even if one does decode the entire full resolution image into a tiled data structure (say, GeglBuffer), there's no need to create a Cairo surface for the entire image at 1:1 zoom. All that's needed is a surface to represent the visible area at the visible zoom. That's a lot more manageable. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
