Re: An alternative to gdk-pixbuf
On Tue, 11 Sep 2018 at 03:11, Magnus Bergman wrote: > On Tue, 11 Sep 2018 00:07:27 +0200 > Bastien Nocera wrote: > > 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. :( IM joined Google's OSS-Fuzz programme last year: https://github.com/google/oss-fuzz The huge surge in CVEs was caused by that --- they've been fixing one or two a day ever since. Once they are through this very painful process, IM ought to be rather safe. I do agree though that it's a large and complex thing to use for such a (relatively) simple task. 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 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 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: has anyone valgrind'd gtk?
On 12/6/06, John Cupitt <[EMAIL PROTECTED]> wrote: > If you have a leak and a testcase (and a patch, even better), open a > bug in bugzilla. I've had good experiences with this ... the few bugs Sorry, I should have included the link: http://bugzilla.gnome.org/ Register, then look for the component you've found the leak in, check there's nothing there already, and open a new bug. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: has anyone valgrind'd gtk?
On 12/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The reality is that gtk is leaking. It could well be, but I'd be a bit surprised. Every few months of hacking I try to take the time to get my project to valgrind cleanly. It's about 100,000 lines of C in the UI part. The only leaks I see in GTK are static initialisation (maybe I'm not pushing GTK very hard). > My REAL QUESTION(s) are who do I report fixes to? (quickly backed up by: if I > need help understanding what's going on, and specifically, why something isn't > being freed in the first place, who do i ask) ? If you have a leak and a testcase (and a patch, even better), open a bug in bugzilla. I've had good experiences with this ... the few bugs I've found and patched have been added to gtk cvs within a couple of days. Questions about gtk internals are probably best directed to gtk-devel-list. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: has anyone valgrind'd gtk?
On 12/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > i have an application, and i'm noticing some leaks deep within gtk's > libraries. GTK doesn't free memory that is just allocated once (usually on startup). It should free memory that gets allocated for widgets though. So you should not see your heap size growing (except through fragmentation) with runtime. There are flags you can set to make GTK easier to valgrind. Federico had a nice post about this on his blog: http://primates.ximian.com/~federico/news-2006-04.html#memory-debugging-infrastructure John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: problem when Profiling Gtk+............plz help
On 10/5/06, Sharma Nitin-A21652 <[EMAIL PROTECTED]> wrote: > Can someone please help with the tool that is in use in Gtk+ development > community for profiling towards identifying functions that take most of the > time in performance? A lot of people use sysprof: http://www.daimi.au.dk/~sandmann/sysprof it can see how kernel time is being used too, very handy. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Invert characters' rendering when text cursor is fat
On 9/4/06, Masatake YAMATO <[EMAIL PROTECTED]> wrote: > Could you give me a mail if you read this message? > Also please, give me hints for the reason why I cannot get any ack > from gtk+ developers. (disclaimer: I'm not a GTK developer) Your bugzilla entry is very general. If you submit this as a bug to a specific component (maybe textview?) it might get more attention, since textview has a particular developer watching it. Also, changing the aspect ratio is not enough to get a block cursor. You'll find the positioning is wrong, since a true block cursor (like the one in "terminal") needs to be shifted to the right (or maybe the left in L to R scripts). And the width should change to match either the current character, or perhaps the space character at the end of line or end of file. Finally, I'm not certain XORing will be enough to always render an inverted character correctly. It would probably be better to redraw the character with the foreground / background colours swapped. (Incidentally, xor-ing a block cursor is patented, though perhaps the patent has lapsed now, I've not checked) Finally, there is a bug there for a block cursor with a patch: http://bugzilla.gnome.org/show_bug.cgi?id=345818 It seems to have become blocked on some architectural issues. I don't know if it inverts. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: strange trouble in displaying a 8bit monochromy grey scale image
On 6/2/06, John Cupitt <[EMAIL PROTECTED]> wrote: memset( p, sizeX * sizeY * 3, pixel_value ) Ahem, of course that should be memset (p, pixel_value, sizeX * sizeY * 3); ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: strange trouble in displaying a 8bit monochromy grey scale image
On 6/2/06, heavenscape <[EMAIL PROTECTED]> wrote: char* pDisplayBuf = malloc(sizeX*sizeY*3); for(i=0;i This isn't going to work. You're only filling the first third of the memory area. How about (untested): // malloc() can return NULL: you need to test the result // g_malloc() cannot fail char *p = g_malloc(sizeX * sizeY * 3); char *q; int i; // i loops for number of pixels // q loops pointing at each RGB triplet in turn for (q = p, i = 0; i < sizeX * sizeY; i++, q += 3) q[0] = q[1] = q[2] = pixel_value; // or alternatively in this special case memset( p, sizeX * sizeY * 3, pixel_value ) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ >> Cocoa Native Port
There's a project page with a TODO list of things that still need fixing: http://developer.imendio.com/wiki/Gtk_Mac_OS_X Might be a start point. On 5/16/06, Matthias Clasen <[EMAIL PROTECTED]> wrote: On 5/16/06, Ben Hall <[EMAIL PROTECTED]> wrote: > So!! I was wondering if any of you had any information and tips > relating to this.. and if their was any actively projects I could > join in on. It is included in GTK+ 2.9.x. Just configure with --gdk-target=quartz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposition for platform maximum filename/pathname length symbols
On 12/24/05, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > While I have the list's attention, it would be nice to add stat() and > fstat() "wrappers" that would definitely be large file aware on all > platforms. Large-file wrappers for ftruncate() and lseek() would be very handy too. Win32 (as far as I know) does not have automatic macros for these either. I have these wrappers in a project of mine which I guess could be made into a patch pretty easily. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Memory consumption
On 11/25/05, Andrey Karavaev <[EMAIL PROTECTED]> wrote: > How about reducing of memory consumption(may be in next GTK+ versions..) ? > Problem is following: even very simple GTK-application takes huge place > in memory(& resident memory) so if we have multiuser sysem . Memory use can be hard to measure. "ps" shows a "hello world" program on my ubuntu machine at 11MB, but looking at /proc/xx/status I see that 'only' 810kb have actually been allocated. If I add a second label and a vbox to hold the two labels, memory use goes up to 812kb. I guess a chunk of this 2kb is down to the theme (clearlooks, I think). (Hope I've not misunderstood you here) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sun's fopen() fd limit of 256
On 11/23/05, John Cupitt <[EMAIL PROTECTED]> wrote: > int g_seek( int fd, gint64 pos ); > int g_ftruncate( int fd, gint64 pos ); > gint64 g_read( int fd, void *buf, gint64 count ); Ahem, that was stupid, forget the g_read() there. Sorry. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sun's fopen() fd limit of 256
On 11/23/05, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN <[EMAIL PROTECTED]> wrote: > Is there any benefit to providing a full GLib fopen/fread/fwrite/etc API which > provides its own implementation if the system implementation has an fd > limitation? The configure script could detect this and enable it if necessary. A related thing I've had problems with is LARGEFILE support on win32. If you need to read()/seek()/truncate() a >2GB file you need to drop down to the plain win32 API (unless there's a clever #define I've not found). Something like: int g_seek( int fd, gint64 pos ); int g_ftruncate( int fd, gint64 pos ); gint64 g_read( int fd, void *buf, gint64 count ); Would be useful for me at least. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A springs and struts widget for GTK+
On 8/16/05, Michael Torrie <[EMAIL PROTECTED]> wrote: > Is this system similar to what QT uses? If I recall correctly, I > remember trying to figure out how to use these spring-like things to do > layout. It was very confusing and I never did figure out how to > properly use them. I remember wishing QT had a layout system more like > GTK's, which is easier to use and understand, GUI designers > notwithstanding. It also sounds rather like XmForm, the main Motif layout manager. The main problem I remember from XmForm was its complexity: every version of Motif had an XmForm widget with different bugs and features (some allowed width / height circularities, which was actually very useful and the only easy way to lay out a scrolled window if you needed to lay it out yourself). So your code had to be rather convoluted to be able to work well wth most Motifs. I think XDesigner had the only reasonable GUI for XmForm. You drew different sorts of lines and arrows between elements to indicate constraints. But it still wasn't easy to use. I think GTK's idea of removing layout iteration (all layout is single-pass, unlike Xt) and using efficient and simple layout widgets in combination is much easier to understand. The addition of size groups removed (I think, almost) the last thing that was easier with a constraint-based layout container. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkImage animation performance
On Wed, 30 Mar 2005 19:37:16 +0300, Komulainen Tommi (Nokia-M/Helsinki) <[EMAIL PROTECTED]> wrote: > I was wondering if there were some good reasons for animations to go > through the whole redraw queuing all the time? Couldn't the next frame > be drawn directly instead? I'm not a gtk guru, but my guess would be that decoupling the timeout and the redraw makes it easy to drop frames if the processor is too slow for the animation. Also, gtk's double buffering will only work well if drawing is restricted to just the "expose" handler. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Future of GtkTooltips
On Wed, 09 Feb 2005 13:23:34 +0100, Christian Neumair <[EMAIL PROTECTED]> wrote: > To be honest, I'm not sure whether it is useful to group tooltips > together in GtkTooltips at all. Is this used? Aren't tooltips usually > describing widget's functions independently from other widgets? I think the groups are to allow tooltip delay eliding: there's a hover pause before popping the first tip up, but after that as the user moves the mouse other tips in the same group pop up immediately. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
