Re: An alternative to gdk-pixbuf

[Debarshi Ray <rishi is lostca se>]

On Mon, Sep 10, 2018 at 09:40:13AM +0100, jcupitt 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.