The GIMP Homepage (http://www.gimp.org) | The GIMP News Archive (http://www.xach.com/gimp/news/index.html) | The GIMP Mailing Lists (http://www.gimp.org/mailing_list.html) | The GIMP FAQ (http://www.rru.com/~meo/gimp/)
Table Of Contents
|1.||5 Apr 2001 - 9 Apr 2001||(12 posts)||Speed-up for Bumpmap|
|2.||5 Apr 2001 - 9 Apr 2001||(10 posts)||Whirl and Pitch|
|3.||8 Apr 2001 - 9 Apr 2001||(4 posts)||CMYK Images|
|4.||9 Apr 2001||(2 posts)||PNG/Netscape Incompatibilities|
|5.||10 Apr 2001||(1 post)||Update Your Translations!|
|6.||15 Apr 2001||(1 post)||Gimp-Print 4.1.6|
Mailing List Stats For This Week
We looked at 39 posts in 162K.
There were 17 different contributors. 8 posted more than once. 5 posted last week too.
The top posters of the week were:
1. Speed-up for Bumpmap
5 Apr 2001 - 9 Apr 2001 (12 posts) Archive Link: "[patch] unbelievable speedup for bumpmap..."
People: Ernst Lippe, Kelly Martin, , Austin Donnelly
Georg Acher submitted a patch that greatly increased the speed of bumpmapping by getting and writing 32 rows at a time. Georg added that the performance issue was with gimp_pixel_rgn_get/set_row-calls in Gimp 1.2.1. Austin Donnelly suggested that most plugins should be using gimp_pixel_rgns_register() and gimp_pixel_rgns_process() functions instead, since they do blocking on a per tile basis. He suggested looking at whirl-pinch for examples of more complex access patterns. Ernst Lippe thought the speedup was caused by better caching, since it looks like all tiles are read and written gimp_tile_height (normally 64) times. Ernst submitted a patch that was similar, but allowed each tile to be read only once. He suspected that the algorithm could be rewritten so that only 3 tiles are needed at a time by using 3 extra buffer columns instead of 3 extra buffer rows. Kelly Martin noted that bumpmap.c calls gimp_tile_cahce_ntiles, which my not be asking for enough cache (or it could be a problem in the tile caching code.) Kelly also suggested using a pixel region iterator since the bumpmap need not be the same size on input and output.
Ernst Lippe offered to clean up some personal code that handled
neighborhoods without fetching tiles multiple times.
Austin Donnelly thought the core could use some tile convolution
code, since it currently copies data
Actually, the core could do with a tile convolution, since currently
it copies data into a tempbuf before convolving it. This makes some
tools more effificient (or incorrect) eg iscissors.
Ernst had several design considerations
There were no more posts in the thread
2. Whirl and Pitch
5 Apr 2001 - 9 Apr 2001 (10 posts) Archive Link: "[patch] Major speedup for whirl&pinch plugin"
People: Ernst Lippe, Kelly Martin,
Georg Acher posted a patch to whirl&pitch to the list. The patch uses blocking to affect a 4.5x increase in performance without changing the main algorithm. Kelly Martin thought whirl&pitch used tile regions for this, but later responded that this was not that case and thought pixel regions might provide less of a loss due to locality. Georg noted that the locality was good between the source and destination, which was what really mattered. Ernst Lippe suggested that there were no major differences in CPU time between Georg's method and the old way. The differences lie in the number of calls to gimp_tile_get and gimp_tile_put. " Requesting tiles from the main Gimp process is pretty expensive, it involves several context switches and a lot of copying. This is orders of magnitude slower than copying data within the plugin process from the tile cache to some other buffer. The whirlpinch plugin uses a cache size that is only big enough to handle the output tiles, there is no room for input tiles. This leads to a series of cache misses and horrible performance. Your modifications improve the cache-hit ratio because it " [...] " The more fundamental solution is to rewrite the algorithm so that it works on a tile by tile basis. In that case the minimum cache size is only 2 (for the output tiles) plus the number of input tiles that are needed to compute one output tile. Of course it is better to use a somewhat larger cache size because adjacent output tiles can use the same input tiles. "
Georg also asked if there was a default tile size that helped caching. Kelly said the default tile size was 64x64, and that changing this made .xcf files non-transportable. " I tried to modify the XCF loader & saver once to do reblocking, but it gave me a headache and I moved on to other, more interesting things, like feeding my cats. :)"
3. CMYK Images
8 Apr 2001 - 9 Apr 2001 (4 posts) Archive Link: "Problem with CMYK TIF"
People: Nick Lamb, , Ulrich Windl
Ulrich Windl had problems loading a .TIF image into the Gimp. The image had no progress bar and ended up rotated 180°. Ulrich wondered if the .TIF used LAB colors, not CMYK. He also mentioned something about a dialog box he didn't read. Ville Pätsi pointed out that the Gimp didn't currently have support for the CMYK colorspace, but it was planned for a 2.0.X release. Nick Lamb added " [t]he dialog box who's contents you don't remember warned you that this would happen - read the warning dialogs!"
4. PNG/Netscape Incompatibilities
9 Apr 2001 (2 posts) Archive Link: "PNG/Netscape incompatibilities?"
People: Ulrich Windl, , Simon Budig
Ulrich Windl's problem with .PNG files was as follows: "The black pixels all appear white in Netscape, while in Amaya or xv the appear OK. I made PNGs the same way with older versions of GIMP, not having that problem." Simon Budig responded that this was a Netscape bug. The solution was to select black as background-color and check the "save background color" button in the PNG-Save dialog.
5. Update Your Translations!
10 Apr 2001 (1 post) Archive Link: "Update Your Translations!"
People: Sven Neumann, Sven Neumann ,
Sven Neumann posted the following note to the developer's list:
" I have just committed a patch to the stable gimp branch that marks a few leftover strings for translations. Translators that are interested in getting a full translation into 1.2.2, update your po-files now! "
6. Gimp-Print 4.1.6
15 Apr 2001 (1 post) Archive Link: "ANNOUNCE: Gimp-Print 4.1.6 release"
People: Robert L Krawitz,
Robert L Krawitz posted the following announcement about Gimp-Print 4.1.6:
This is gimp-print version 4.1.6, a development release on the 4.1 line.
This software includes the Print plug-in for the Gimp, and GhostScript and CUPS drivers. The support for printers in GhostScript and CUPS is identical to the support for these printers in the Print plugin -- they use the identical code base. Please read src/ghost/README and src/cups/README for more information on this.
The Gimp Print plugin requires the Gimp 1.2.
Gimp-Print 4.1.6 contains the following changes over 4.1.6:
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.