Re: An alternative to gdk-pixbuf
On Thu, 6 Sep 2018 11:39:59 +0100 Emmanuele Bassi wrote: > On Wed, 5 Sep 2018 at 19:25, Magnus Bergman > wrote: > > > On Wed, 5 Sep 2018 17:28:22 +0100 > > Emmanuele Bassi wrote: > > > > > We're phasing out Cairo in favour of the CSS rendering model, > > > implemented on top of OpenGL and Vulkan, as it's the API that most > > > closely matches the requirements of GTK. > > > > I'm not sure I quite understand what you are saying. What does this > > mean for image loading if terms of actual implementation? What would > > ideally happen then GTK+ needs to load an image (because the > > application called gtk_image_new_from_file() for example)? > > > > > We're still using GdkPixbuf, and for the 4.0 API series we still have > GdkPixbuf types exposed in the GTK API. > > For future API series (5.x, 6.x, …) we may revisit this, with the > option of moving icon loading into GTK itself. Okay, sound reasonable. > > > Cairo is still used as a fallback mechanism — both when running on > > > platforms without support for OpenGL or Vulkan, and in the interim > > > period while the GL/Vulkan rendering pipelines inside GTK don't > > > support a CSS feature. Additionally, you may still use Cairo for > > > 2D high quality rendering, for printing and for custom drawing. > > > > But then it comes to printing and custom drawing I'm on my own then > > it comes to loading the images? Which is okey of course since > > gdk-pixbuf is kind of a separate library already. But isn't it a > > good thing to share common image loading code? > > > > Not really; icons—especially ones that are identified via icon theme > names—are a very narrow subset of "all the possible images and > formats in human history". > > > 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. I often deal with images of those sizes and I haven't experienced any problems with this myself (sure it's not as fast as viewing small images). But I will look into it. I though cairo was capable of utilising the rendering back end for it's scaling. I don't see why cairo NEEDS to use CPU-scaling, so maybe it can be fixed. > > It doesn't do animation > > Animated formats are a dying breed, and they have all but killed by > VP9 and new, web-friendly video formats. Social platforms will take a > GIF and turn it into a video transparently. > > Additionally, GTK 4.x already has new API to render videos and other > frame-based media sources through GStreamer. I must agree this sounds like a good decision. Even though I don't think animated GIFs will die any time soon, it's not really anything GTK+ should need to pay special attention to. From my perspective, being interested in the art scene, animation might not be very common, but formats supporting animation certainly are. It's not only in the form of a series of frames (like GIF), it's also palette cycling, or simply one blinking color I include in the concept of animation. I've also seen image formats that shows the current time. Those, I think, should ideally be displayed with the time updating. So that's also a kind of animation. Does GStreamer support vector animations, by the way? > > > From the perspective of a consumer of GdkPixbuf, the only thing > > > that > > > an image loading library should do is, pretty literally, load > > > images. No scaling, no compositing, no rendering. Saving to a > > > file may be interesting — but that opens the whole transcoding > > > can of worms, so maybe it should just be a debugging feature. > > > Ideally, I/O operations should happen in a separate thread, and > > > possible use multi-threading to chunk out the work on multiple > > > cores; it definitely needs to integrate with GIO, as it's a > > > modern API that well maps to GUIs. > > > > Yes, I very much agree with this. Except I think it has to do > > rendering of some sort. If an image contains a triangle, it has to > > be converted to a function call that renders it (using > > OpenGL/Vulcan/cairo) somehow. > > That's up to the toolkit, as it's going to be the one deciding how to > render the rest of the UI. There's no way for you to know, from the > outside, how to efficiently render anything. > > That's why it's much, much better to get a memory buffer with the > contents of the image, and let the toolkit pass it to the GPU. > > Vector formats are different, but that's why we have API like Cairo or > Skia; I'm also waiting for web browsers to implement SVG rendering on > the GPU where possible, with the help of new primitives from the > GL/Vulkan implementation. That means one code path for images that are certainly raster based and another
Re: An alternative to gdk-pixbuf
On Wed, 2018-09-05 at 17:28 +0100, Emmanuele Bassi via gtk-devel-list wrote: > In the near future, I'll very likely deprecate most of GdkPixbuf's > API, except for the I/O operations; I'd also be happy to seal off > most of its internals, within the ABI stability promise, to avoid > leakage of internal state. Related to this - I just wrote a braindump on gdk-pixbuf issues and historical baggage. I hope it's useful for people trying to clean up this swamp: https://people.gnome.org/~federico/blog/my-gdk-pixbuf-braindump.html Magnus - thanks for showing us Abydos. The parts of the API that intersect with gdk-pixbuf's look okay. I think you may find this useful: https://developer.gnome.org/programming-guidelines/stable/index.html.en I think your API could improve with some of the material there around memory management and error reporting. Internally, the code needs checks in all the malloc()-like functions; some of the arithmetic (especially in assertions) needs to avoid overflows. I couldn't find any tests. The SVG plug-in needs to handle error results from librsvg. The Magick plug-in for PNG and JPEG has no error handling; also you may want to call cairo_surface_mark_dirty() when you are done writing pixels to it. The netpbm plugin does a bunch of system calls and doesn't check for errors. The parts of your API that deal with pagination / variants / animation frames - I'm not sure if a gdk-pixbuf replacement would need them, but I'm coming from the viewpoint of my braindump above. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with git.gnome.org
Are you trying to access a repository using a `git://` URL? That has been deprecated a long time ago, for security reasons, and with GitLab it was removed altogether. Ciao, Emmanuele. On Thu, 6 Sep 2018 at 14:09, John Emmas wrote: > Hi guys - sorry for posting this here but I've tried gnome's > 'gitlab-issues' mailing list and couldn't get any response. Maybe > someone here can help..? > > For the past few weeks I've been seeing errors if I try to update (i.e. > pull) certain libraries from git (e.g. pango / pangomm / gtkmm etc). > Here's what I see... > > Looking up git.gnome.org ... done. > Connecting to git.gnome.org (port 9418) ... fatal: unable to > connect to git.gnome.org > git.gnome.org[0: 209.132.180.168]: errno=No error > git.gnome.org[1: 209.132.180.180]: errno=No error > > At first I assumed the repos were down temporarily but it's not getting > any better so I'm guessing the libraries have been moved somewhere > else? So do I maybe need to change something at my end? > > It doesn't seem to be affecting all my gtk support libs BTW - just some > of them... Thanks, > > John > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with git.gnome.org
On Thu, 2018-09-06 at 15:30 +0100, John Emmas wrote: > On 06/09/2018 14:11, Bastien Nocera wrote: > > > > It's gitlab.gnome.org, not git.gnome.org anymore. > > > > Thanks Bastien - but that doesn't seem to help... :-( > > I see exactly the same error except that whereas it previously said > "fatal: unable to connect to git.gnome.org" it now tells me:- > "fatal: > unable to connect to gitlab.gnome.org" > > Is the remote at 'git://gitlab.gnome.org' or somewhere else (https:// > > maybe) ? You can find the new git URI for each project by going to the project’s page on GitLab: https://gitlab.gnome.org/GNOME/pango The clone URI is in the middle at the top, just below the project logo and name. You get the choice of HTTPS or (if you’re logged in) SSH. Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with git.gnome.org
On 06/09/2018 14:11, Bastien Nocera wrote: It's gitlab.gnome.org, not git.gnome.org anymore. Thanks Bastien - but that doesn't seem to help... :-( I see exactly the same error except that whereas it previously said "fatal: unable to connect to git.gnome.org" it now tells me:- "fatal: unable to connect to gitlab.gnome.org" Is the remote at 'git://gitlab.gnome.org' or somewhere else (https:// maybe) ? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with git.gnome.org
On Thu, 2018-09-06 at 14:09 +0100, John Emmas wrote: > Hi guys - sorry for posting this here but I've tried gnome's > 'gitlab-issues' mailing list and couldn't get any response. Maybe > someone here can help..? > > For the past few weeks I've been seeing errors if I try to update > (i.e. > pull) certain libraries from git (e.g. pango / pangomm / gtkmm etc). > Here's what I see... > > Looking up git.gnome.org ... done. It's gitlab.gnome.org, not git.gnome.org anymore. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Problems with git.gnome.org
Hi guys - sorry for posting this here but I've tried gnome's 'gitlab-issues' mailing list and couldn't get any response. Maybe someone here can help..? For the past few weeks I've been seeing errors if I try to update (i.e. pull) certain libraries from git (e.g. pango / pangomm / gtkmm etc). Here's what I see... Looking up git.gnome.org ... done. Connecting to git.gnome.org (port 9418) ... fatal: unable to connect to git.gnome.org git.gnome.org[0: 209.132.180.168]: errno=No error git.gnome.org[1: 209.132.180.180]: errno=No error At first I assumed the repos were down temporarily but it's not getting any better so I'm guessing the libraries have been moved somewhere else? So do I maybe need to change something at my end? It doesn't seem to be affecting all my gtk support libs BTW - just some of them... Thanks, 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 Thu, 6 Sep 2018 at 11:40, Emmanuele Bassi via gtk-devel-list wrote: > On Wed, 5 Sep 2018 at 19:25, Magnus Bergman > 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. It doesn't have to be gegl, of course, you could use any image processing library to load and scale down the images. I made a tiny image viewer based on libvips: https://github.com/jcupitt/vipsdisp-tiny It's 300 lines, but does multi-threaded, asynchronous painting of many image formats. It can display gigapixel images on very modest hardware, and it should be quick. There's a more complete image viewer here: https://github.com/jcupitt/vipsdisp That adds most of the usual navigation stuff, though it's not quite done, I must get back to it. The image display part is a widget you could easily cut out and paste into other applications. It's in C, but libvips is a GObject-based library, so it'd be easy to write in any language. Here it is displaying a 18k x 8k 16-bit TIFF: http://www.rollthepotato.net/~john/summer.png That image takes about 8s to load on this laptop. Here it is displaying a 120k x 100k pixel ndpi slide image: http://www.rollthepotato.net/~john/slide.png That image loads instantly, since ndpi supports random access and vipsdisp can just load the parts it needs to paint the screen. 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 Wed, 5 Sep 2018 at 19:25, Magnus Bergman wrote: > On Wed, 5 Sep 2018 17:28:22 +0100 > Emmanuele Bassi wrote: > > > We're phasing out Cairo in favour of the CSS rendering model, > > implemented on top of OpenGL and Vulkan, as it's the API that most > > closely matches the requirements of GTK. > > I'm not sure I quite understand what you are saying. What does this > mean for image loading if terms of actual implementation? What would > ideally happen then GTK+ needs to load an image (because the > application called gtk_image_new_from_file() for example)? > > We're still using GdkPixbuf, and for the 4.0 API series we still have GdkPixbuf types exposed in the GTK API. For future API series (5.x, 6.x, …) we may revisit this, with the option of moving icon loading into GTK itself. > > Cairo is still used as a fallback mechanism — both when running on > > platforms without support for OpenGL or Vulkan, and in the interim > > period while the GL/Vulkan rendering pipelines inside GTK don't > > support a CSS feature. Additionally, you may still use Cairo for 2D > > high quality rendering, for printing and for custom drawing. > > But then it comes to printing and custom drawing I'm on my own then it > comes to loading the images? Which is okey of course since gdk-pixbuf > is kind of a separate library already. But isn't it a good thing to > share common image loading code? > Not really; icons—especially ones that are identified via icon theme names—are a very narrow subset of "all the possible images and formats in human history". 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. > It doesn't do animation Animated formats are a dying breed, and they have all but killed by VP9 and new, web-friendly video formats. Social platforms will take a GIF and turn it into a video transparently. Additionally, GTK 4.x already has new API to render videos and other frame-based media sources through GStreamer. > From the perspective of a consumer of GdkPixbuf, the only thing that > > an image loading library should do is, pretty literally, load images. > > No scaling, no compositing, no rendering. Saving to a file may be > > interesting — but that opens the whole transcoding can of worms, so > > maybe it should just be a debugging feature. Ideally, I/O operations > > should happen in a separate thread, and possible use multi-threading > > to chunk out the work on multiple cores; it definitely needs to > > integrate with GIO, as it's a modern API that well maps to GUIs. > > Yes, I very much agree with this. Except I think it has to do rendering > of some sort. If an image contains a triangle, it has to be converted to > a function call that renders it (using OpenGL/Vulcan/cairo) somehow. > That's up to the toolkit, as it's going to be the one deciding how to render the rest of the UI. There's no way for you to know, from the outside, how to efficiently render anything. That's why it's much, much better to get a memory buffer with the contents of the image, and let the toolkit pass it to the GPU. Vector formats are different, but that's why we have API like Cairo or Skia; I'm also waiting for web browsers to implement SVG rendering on the GPU where possible, with the help of new primitives from the GL/Vulkan implementation. > In the near future, I'll very likely deprecate most of GdkPixbuf's > > API, except for the I/O operations; I'd also be happy to seal off > > most of its internals, within the ABI stability promise, to avoid > > leakage of internal state. > > Will the loader plugin API go away, you think? > No API will ever go away: there are no plans for a gdk-pixbuf-3.0. The deprecations would mostly apply to API that is either long since been replaced by Cairo (scale/composite), or that is weirdly ad hoc, like saturate_and_pixelate(). Ideally, I'd like to deprecate the option to build gdk-pixbuf without depending on GIO to do MIME type sniffing, as GIO has been fixed to work on Windows and macOS, and it is a required dependency anyway. 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
