On Mon, 10 Sep 2018 at 08:02, Debarshi Ray <rishi...@lostca.se> 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
