Re: [patch] batch scanlines when loading JPEG...
Hi Federico, On Sat, Aug 29, 2009 at 12:27 AM, Federico Mena Quintero wrote: > On Fri, 2009-08-28 at 16:12 +0100, Daniel J Blueman wrote: > >> I've written and tested a small patch that increases efficiency >> (particularly in small-cache systems) of loading JPEG images: override >> the recommended lines with what we've already allocated; increase >> batch size from 4 to 8 lines. > > Thanks for trying to make JPEG loading faster; we could certainly use > that :) A few comments: > First, did you actually test that patch (did you send the wrong one)? > The last hunk doesn't compile: > + /* batch line updates f or efficiency */ > + cinfo->rec_outbuf_height = cinfo.rec_outbuf_height > > LINEBUF_SIZE ? cinfo.rec_outbuf_height : LINEBUF_SIZE; > + > > That should be "cinfo->blah" instead of "cinfo.blah". Oops. Looks like I didn't rediff after fixing that. > Second, that test looks wrong: > > cinfo.rec_outbuf_height = cinfo.rec_outbuf_height > LINEBUF_SIZE ? > cinfo.rec_outbuf_height : LINEBUF_SIZE; > > I just checked the libjpeg sources and it will never return > cinfo.rec_outbuf_height larger than 4. Thus, the test is redundant. > However, if libjpeg ever changes and sets rec_outbuf_height to something > larger than our LINEBUF_SIZE, you'll be trampling over memory as the > lines array is not big enough. Yes, it's clearly better to assign it to the array size - fixed, attached for consideration. > Third, I ran a quick benchmark with > > /usr/bin/time eog image.jpg > > for a 39 MB JPEG (a 11299x10764-pixel satellite image which expands t o > about 360 MB in RAM). Both without your patch and with the patch, it > loads consistently in about 11.3 seconds. I couldn't measure any > difference. The aim is to increase cache effectiveness on small-cache systems (ARM etc). The increase will be small, but makes good use of the line pointer array and code already in place. When colourspace conversion is performed, there may be additional improvement from better locality - it's a start. On a separate note, is your 39MB JPEG progressively encoded? Daniel -- Daniel J Blueman diff --git a/gdk-pixbuf/io-jpeg.c b/gdk-pixbuf/io-jpeg.c index 680a209..77a37e6 100644 --- a/gdk-pixbuf/io-jpeg.c +++ b/gdk-pixbuf/io-jpeg.c @@ -46,6 +46,7 @@ /* we are a "source manager" as far as libjpeg is concerned */ #define JPEG_PROG_BUF_SIZE 65536 +#define LINEBUF_SIZE 8 typedef struct { struct jpeg_source_mgr pub; /* public fields */ @@ -454,7 +455,7 @@ gdk_pixbuf__jpeg_image_load (FILE *f, GError **error) char otag_str[5]; GdkPixbuf * volatile pixbuf = NULL; guchar *dptr; - guchar *lines[4]; /* Used to expand rows, via rec_outbuf_height, + guchar *lines[LINEBUF_SIZE]; /* Used to expand rows, via rec_outbuf_height, * from the header file: * " Usually rec_outbuf_height will be 1 or 2, * at most 4." @@ -511,6 +512,9 @@ gdk_pixbuf__jpeg_image_load (FILE *f, GError **error) cinfo.do_fancy_upsampling = FALSE; cinfo.do_block_smoothing = FALSE; + /* batch line updates for efficiency */ + cinfo.rec_outbuf_height = LINEBUF_SIZE; + pixbuf = gdk_pixbuf_new (GDK_COLORSPACE_RGB, cinfo.out_color_components == 4 ? TRUE : FALSE, 8, cinfo.output_width, cinfo.output_height); @@ -738,7 +742,7 @@ gdk_pixbuf__jpeg_image_load_lines (JpegProgContext *context, GError **error) { struct jpeg_decompress_struct *cinfo = &context->cinfo; -guchar *lines[4]; +guchar *lines[LINEBUF_SIZE]; guchar **lptr; guchar *rowptr; gint nlines, i; @@ -968,6 +972,9 @@ gdk_pixbuf__jpeg_image_load_increment (gpointer data, cinfo->do_fancy_upsampling = FALSE; cinfo->do_block_smoothing = FALSE; + /* batch line updates f or efficiency */ + cinfo->rec_outbuf_height = LINEBUF_SIZE; + if (rc == JPEG_SUSPENDED) continue; ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[patch] batch scanlines when loading JPEG...
Hi guys, I've written and tested a small patch that increases efficiency (particularly in small-cache systems) of loading JPEG images: override the recommended lines with what we've already allocated; increase batch size from 4 to 8 lines. Please consider for inclusion and tweak as needed (eg reducing the batch size to the original limit of 4). Many thanks, Daniel Signed-off-by: Daniel J Blueman -- Daniel J Blueman diff --git a/gdk-pixbuf/io-jpeg.c b/gdk-pixbuf/io-jpeg.c index 680a209..77a37e6 100644 --- a/gdk-pixbuf/io-jpeg.c +++ b/gdk-pixbuf/io-jpeg.c @@ -46,6 +46,7 @@ /* we are a "source manager" as far as libjpeg is concerned */ #define JPEG_PROG_BUF_SIZE 65536 +#define LINEBUF_SIZE 8 typedef struct { struct jpeg_source_mgr pub; /* public fields */ @@ -454,7 +455,7 @@ gdk_pixbuf__jpeg_image_load (FILE *f, GError **error) char otag_str[5]; GdkPixbuf * volatile pixbuf = NULL; guchar *dptr; - guchar *lines[4]; /* Used to expand rows, via rec_outbuf_height, + guchar *lines[LINEBUF_SIZE]; /* Used to expand rows, via rec_outbuf_height, * from the header file: * " Usually rec_outbuf_height will be 1 or 2, * at most 4." @@ -511,6 +512,9 @@ gdk_pixbuf__jpeg_image_load (FILE *f, GError **error) cinfo.do_fancy_upsampling = FALSE; cinfo.do_block_smoothing = FALSE; + /* batch line updates for efficiency */ + cinfo.rec_outbuf_height = cinfo.rec_outbuf_height > LINEBUF_SIZE ? cinfo.rec_outbuf_height : LINEBUF_SIZE; + pixbuf = gdk_pixbuf_new (GDK_COLORSPACE_RGB, cinfo.out_color_components == 4 ? TRUE : FALSE, 8, cinfo.output_width, cinfo.output_height); @@ -738,7 +742,7 @@ gdk_pixbuf__jpeg_image_load_lines (JpegProgContext *context, GError **error) { struct jpeg_decompress_struct *cinfo = &context->cinfo; -guchar *lines[4]; +guchar *lines[LINEBUF_SIZE]; guchar **lptr; guchar *rowptr; gint nlines, i; @@ -968,6 +972,9 @@ gdk_pixbuf__jpeg_image_load_increment (gpointer data, cinfo->do_fancy_upsampling = FALSE; cinfo->do_block_smoothing = FALSE; + /* batch line updates f or efficiency */ + cinfo->rec_outbuf_height = cinfo.rec_outbuf_height > LINEBUF_SIZE ? cinfo.rec_outbuf_height : LINEBUF_SIZE; + if (rc == JPEG_SUSPENDED) continue; ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.17.10 released
GTK+ 2.17.10 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.17/ http://download.gnome.org/sources/gtk+/2.17/ md5 sums: 9fe31cc177993fdec187e6f44fc3b60b gtk+-2.17.10.tar.bz2 b169d880f5b672219e23f8fb9cf764ab gtk+-2.17.10.tar.gz sha1 sums: 093b6019525786f1f8112a989d7c1bbc168bbd42 gtk+-2.17.10.tar.bz2 91bb6aebe1b73fb17918416d0c1b56415d547b03 gtk+-2.17.10.tar.gz This is a development release leading up to GTK+ 2.18. Notes: * This is an unstable development release. It has had only little testing and there are unfinished features and plenty of bugs in this release. It should definitively not be used in production. * Installing this version will overwrite your existing copy of GTK+ 2.16. If you have problems, you'll need to reinstall GTK+ 2.16. * GTK+ 2.18 will be source and binary compatible with the GTK+ 2.16 series; however, the new API additions are not yet finalized, so there may be incompatibilities between this release and the final 2.18 release. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.17.9 to 2.17.10 === * Client-side windows: - Regression fixes continue - Multiple clipping issues have been fixed - gdk_window_beep() works again - gtk-demo now has a few offscreen window demos * GSEAL: - Several more getters and setters have been added: gtk_widget_is_toplevel(), gtk_widget_is_drawable(), gtk_widget_set_window() * Bugs fixed: 592752 aisleriot card drag start makes card appear behind... 592901 Crash in JPEG pixbuf loader instead of error 592263 redraw problem in text view 593011 Cannot move applet with middle click 592624 BadAccess from gdk_window_x11_set_events 592606 Activate the default button in a respose-request callback 593249 emacs and acroread don't work properly 592883 Spin cell rendererer problem with double click 588199 GtkTreeView rendering glitch while using a default... 543310 set_enable_tree_lines doesn't work when a cellrenderer... 589636 csw broke DND from panel menus 593595 broken clip handling in GtkLabel 590921 NULL should not be a valid return value for gdk_window_new() 590861 cups_printer_create_cairo_surface() sets a fallback res... 544724 delete new line requires two keystrokes 593001 Emit 'update-custom-widget' on page setup change 593317 gtkwindow leaks startup ID 593080 mem leak 593481 GtkEntryCompletion action-activated signal is emitted... 593135 gtk_entry_set_icon_from_pixbuf only works one time 593012 configure doesn't handle --enable-{cups,papi} correctly 592862 There is a misprint on the returning value of gdk_pixmap... 586466 GtkPrintOperation printing fails if it is the only... 434318 printer detail acquisition needs events 593712 configure fails to to check properly for cups... * Translation updates: Asturian Basque Bengali India Czech Finnish Hindi Kannada Oriya Polish Serbian Tamil Telugu Thanks to all contributors: Alexander Larsson Christian Dywan Benjamin Otte Dan Winship Kristian Rietveld Michael Natterer Pascal Terjan Carlos Garcia Campos Christian Persch Davyd Madeley Marek Kasik Paolo Borelli September 1, 2009 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended input device breakage
On Sun, 2009-08-30 at 18:29 -0400, Thomas Jaeger wrote: > I'd appreciate it if someone could look into those issues, as they are > critical for tablet users in the upcoming round of distributions. > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=588649 I added "csw" to the whiteboard on this bug so it gets on my radar for csw regressions. I'll try to look at it soon. However, i'm really not an expert on xinput & co, so if anyone else would like to help out that would be very nice. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list