Re: Re: Tile Cache Size
[Lots of people writing barking mad things about tile swapping] Look, you're all missing the point. Gimp does it's own tile swapping not because it wants to control the layout on disk. As some of you have pointed out, this is futile. The only reason to swap a tile at a time is to do with controlling how far apart in memory neighbouring pixels are. Consider a very wide image. If it is stored as a large linear array in memory (possibly paged by the OS to an OS-managed swap file), then the common operation of consulting a pixel above or below the current one results in needing to skip a large number of bytes through the linear array. This results in poor CPU cache performance. So, we use a tiled memory layout. Once the data is in a tiled representation in memory, there seems little point in converting it into a linear buffer before writing it to disk. This would certainly take more time than it would to just hand the data to the OS. Now, the size of a tile cache (ie number of tiles we'd like to be able to access as speedily as possible) should be a little over the number of tiles it takes to cover the width of the image. This is so that filters which iterate over every single pixel from left to right, top to bottom, perform better on the horizontal boundary between adjacent strips of tiles. Consider a 3x3 convolution (let's say a blur matrix). When the center of the matrix is at the top of the second row of tiles, the top of the matrix needs to reference the first row of tiles. It is helpful for performance to have this top row available. Which means caching ceil(img_width / tile_width) + 1 tiles. And gentlemen, this is not rocket science. It's what undergraduates are normally taught in their basic "OS Functions" lectures. The gimp is a good example of why application-specific paging control can be a performance boost. Now can we drop this silly subject, please? Austin
i18n problem
In recent 1.1.11 or CVS Gimp, there is a problem with i18n. All not-translated
menuitems show up as "File" (in their respective i18n equivalent).
Could someone take a peek at it?
thanks
Jimmac
--
"who's General Failure? And why is he reading my disk?"
@-{ [EMAIL PROTECTED] }---{ http://hideout.musichall.cz }-@
Re: i18n problem
In recent 1.1.11 or CVS Gimp, there is a problem with i18n. All not-translated menuitems show up as "File" (in their respective i18n equivalent). Is your translation table fr.po ? It seems to be broken when I tried to "make update-po". -- yasuhiro
Re: Tile Cache Size
Austin Donnelly wrote: [Lots of people writing barking mad things about tile swapping] Look, you're all missing the point. Gimp does it's own tile swapping not because it wants to control the layout on disk. As some of you have pointed out, this is futile. The only reason to swap a tile at a time is to do with controlling how far apart in memory neighbouring pixels are. Consider a very wide image. If it is stored as a large linear array in memory (possibly paged by the OS to an OS-managed swap file), then the common operation of consulting a pixel above or below the current one results in needing to skip a large number of bytes through the linear array. This results in poor CPU cache performance. So, we use a tiled memory layout. Once the data is in a tiled representation in memory, there seems little point in converting it into a linear buffer before writing it to disk. This would certainly take more time than it would to just hand the data to the OS. Now, the size of a tile cache (ie number of tiles we'd like to be able to access as speedily as possible) should be a little over the number of tiles it takes to cover the width of the image. This is so that filters which iterate over every single pixel from left to right, top to bottom, perform better on the horizontal boundary between adjacent strips of tiles. Consider a 3x3 convolution (let's say a blur matrix). When the center of the matrix is at the top of the second row of tiles, the top of the matrix needs to reference the first row of tiles. It is helpful for performance to have this top row available. Which means caching ceil(img_width / tile_width) + 1 tiles. And gentlemen, this is not rocket science. It's what undergraduates are normally taught in their basic "OS Functions" lectures. The gimp is a good example of why application-specific paging control can be a performance boost. Now can we drop this silly subject, please? Austin okay... now what is the best size to set it to? /me runs *grin* -- Garrett LeSage - Linux.com Art Director [EMAIL PROTECTED] - http://linux.com/
Re: Help System
Uwe Koloska writes: Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally systems without thread support) because it needs the threaded version of strok() strtok_r(). Not to mention it's a bit impossible to build on non-X11 systems ;-) But I'm not complaining. But I (or somebody) will probably eventually write a separate winhelpbrowser plug-in for Windows that just uses the user's default Web browser (Netscape or IE). --tml
problems with MPEG animations
Hello, I use GIMP 1.0.4 on Debian GNU/Linux 2.2 (potato). I download the following mpeg files as examples: http://pages.hotbot.com/arts/hof/images/helen.mpg http://pages.hotbot.com/arts/hof/images/loco.mpg I have no problems with xanim to animate. But GIMP cannot load this files because plug-in mpeg crashes with segfault when loading these files. What do you think, what is my problem? Thanks, -- Serge Gavrilov Institute for Problems in Mechanical Engineering, Laboratory of Hydroelasticity, St.Petersburg, Russia | URL: http://www.ipme.ru/ipme/labs/he/serge.htm
Re: i18n problem
If it is, the german de.po is broken too, since I experience the same weird problem here. What menuitems are replaced by Datei? I could not reproduce the problem. -- yasuhiro
