On Sat, Nov 13, 1999 at 09:42:33PM +0100, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 13, 1999 at 03:32:45AM +, Nick Lamb <[EMAIL PROTECTED]>
>wrote:
Nick, it's a shame that we feel forced to write such mails. This is not
not funny for both of us.
How about, if we both tried very
On Sat, Nov 13, 1999 at 03:32:45AM +, Nick Lamb <[EMAIL PROTECTED]>
wrote:
> On Fri, Nov 12, 1999 at 05:32:10PM +0100, Marc Lehmann wrote:
> > You saying that the tile system in Gimp is faster is not useful.
> ^^^
>
> I didn't. Please don't leap into eve
On Fri, Nov 12, 1999 at 02:51:04PM +0100, Ewald R. de Wit wrote:
> > This has optimal performance when the image data is on disk, and there is
> > precisely enough memory spare to store a duplicate image in memory, and
> > assuming that your disk is very slow and your memory is very fast, which
>
On Fri, Nov 12, 1999 at 05:32:10PM +0100, Marc Lehmann wrote:
> You saying that the tile system in Gimp is faster is not useful.
^^^
I didn't. Please don't leap into every discussion just to bait me Marc,
it's very annoying and I somehow doubt that others are
Marc Lehmann ([EMAIL PROTECTED]) wrote:
> Nick, he claims that his software can do the same operation faster on the
> same machine with a linear memory representation.
>
> So either he lies, he does not know how to measure, his software _is_ twice
> as fast since the tile system in gimp is crap,
On Fri, Nov 12, 1999 at 12:44:14PM +, Nick Lamb <[EMAIL PROTECTED]>
wrote:
> case which can again cost us 2x -- 10x performance without a thought
> on mid-sized or large images.
>
> So Ewald, unless your critique of the Gimp tile system is going to
> get a bit more sophisticated I'd prefer t
Nick Lamb ([EMAIL PROTECTED]) wrote:
> On Fri, Nov 12, 1999 at 11:38:57AM +0100, Ewald R. de Wit wrote:
> > You can always read in the linear file in row order (and write the
> > results in column order to memory in the case of 90 degree rotation).
> > This will go at full disk speed.
>
> This
On Fri, Nov 12, 1999 at 11:38:57AM +0100, Ewald R. de Wit wrote:
> You can always read in the linear file in row order (and write the
> results in column order to memory in the case of 90 degree rotation).
> This will go at full disk speed.
This has optimal performance when the image data is on
Eduardo Perez ([EMAIL PROTECTED]) wrote:
> Performing 'linear' operations on an image (such as color correction) is
> not much slower on the tiled architecture. But 'non-linear' access to
> the image (such as 90 degree rotations) is terribly slow when the image
> has been swapped out. As far as yo
"Ewald R. de Wit" wrote:
>
> Anyway, today I went over the Gimp sources and noticed how complicated
> the tile architecture makes things and I couldn't help wondering why
> the heck it was put in. All it seems to do is to give you an order of
> magnitude slower speed when dealing with large image
On Thu, Nov 11, 1999 at 12:56:58PM +0100, "Ewald R. de Wit" <[EMAIL PROTECTED]> wrote:
> Well the algorithm involved is a simple 256 byte lookup table (or 3 of
> them for each of the RGB channels). There is not much one can screw up
> about it, both performance and precision wise.
The only differ
On Thu, Nov 11, 1999 at 01:40:28AM +0100, Uwe Koloska wrote:
> Nich Lamb wrote on Die, 09 Nov 1999:
> >Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
> >result in the creation of a gimpswap which is up to 500Mb in size?
> >
> Where do you think can the undo information res
Nich Lamb wrote on Die, 09 Nov 1999:
>Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
>result in the creation of a gimpswap which is up to 500Mb in size?
>
Where do you think can the undo information reside???
Uwe
--
mailto:[EMAIL PROTECTED]
http://rcswww.urz.tu-dresden.
Marc Lehmann ([EMAIL PROTECTED]) wrote:
> I really don't agree with you on the speed issue. data is most often
> processed by tile, in which case the program will find an almost ideal
> situation, memory and cache-wise.
If it's not the tile architecture that's causing the inefficiencies,
then wha
On Tue, Nov 09, 1999 at 03:53:11AM +, Nick Lamb wrote:
>
> Further to my last post (and possibly related to Ewald's complaints too)
>
> Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
> result in the creation of a gimpswap which is up to 500Mb in size?
At least earli
On Tue, Nov 09, 1999 at 11:59:58AM +1000, David Bonnell wrote:
> On Tue, 9 Nov 1999, Ewald R. de Wit wrote:
>
> > Anyway, today I went over the Gimp sources and noticed how complicated
> > the tile architecture makes things and I couldn't help wondering why
> > the heck it was put in. All it seem
On Tue, Nov 09, 1999 at 01:27:29AM +0100, "Ewald R. de Wit" <[EMAIL PROTECTED]> wrote:
> 2. The fragmentation of tiles within the swap file. The sound of Gimp
>trashing the harddisk suggests that this is a very big issue.
For which spatial indexing would be solution.
> Anyway, today I went o
x4000. On a
128 MB machine with a tile-cache-size of 80M everything is going
quite slow. Adjusting the tile-cache-size doesn't make things go
faster for me.
If the image doesn't fit into memory then operating on it will take a
long time anyway. IMHO it is silly to optimize for this case a
On Mon, 8 Nov 1999, Andrew Kieschnick wrote:
> Hmm. Are you setting the tile cache size to something reasonable? It will
> definitely suck with the default 10mb tile cache...
>
Bumped it up to 60MB and it's better.
Something as simple has hiding one of the layers takes about
Further to my last post (and possibly related to Ewald's complaints too)
Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
result in the creation of a gimpswap which is up to 500Mb in size?
The performance for such images seems adequate to me (can't compare
PotatoShop beca
On Tue, Nov 09, 1999 at 01:27:29AM +0100, Ewald R. de Wit wrote:
> Anyway, today I went over the Gimp sources and noticed how complicated
> the tile architecture makes things and I couldn't help wondering why
> the heck it was put in. All it seems to do is to give you an order of
> magnitude slowe
; I tried editing a couple of large images yesterday (10MB/600dpi) and it
> was painfully slow (Dual 300MHz PII, 128MB RAM). I've got a 20MB/1200dpi
> one I want to edit and I'm not looking forward to it!
Hmm. Are you setting the tile cache size to something reasonable? It will
definitely suck with the default 10mb tile cache...
later,
Andrew Kieschnick
On Tue, 9 Nov 1999, Ewald R. de Wit wrote:
> Anyway, today I went over the Gimp sources and noticed how complicated
> the tile architecture makes things and I couldn't help wondering why
> the heck it was put in. All it seems to do is to give you an order of
> magnitude slower speed when dealing
Marc Lehmann ([EMAIL PROTECTED]) wrote:
> But this is not at all a problem. For example, on my 8GB main (i.e. /usr,
> /home) partition that I already use since two years ans that is 95% full
> (too full for the file system in question) I have 0.5% fragmentation. Only
> two files have fragmented ch
On Tue, 9 Nov 1999, Guillermo S. Romero / Familia Romero wrote:
> So Gimp could use it, instead of using OS things (swap or filesystem). I
> guess everybody will agree that a partition handled by one process (with
> high performance in mind) is a good solution.
>
What's wrong with using mmap? Y
>> About HD: is there a way to do swap on demand to a partition? A daemon, lib
>> or something?
>is this gimp-related (?) or do you want something like swapd? or swap
>priorities?
I know what swapd and swap priorities are (I think I do, OS thing and how
partitions are used). I am speaking about s
On Tue, Nov 09, 1999 at 12:04:14AM +0100, "Guillermo S. Romero / Familia Romero"
<[EMAIL PROTECTED]> wrote:
> About HD: is there a way to do swap on demand to a partition? A daemon, lib
> or something?
is this gimp-related (?) or do you want something like swapd? or swap
priorities?
> I think t
>I rather think _you_ are missing the point (which is disk layout and
>minimizing seeks, and _not_ a better memory layout. The tile based scheme
>leads itself naturally to spatial indexing, in fatc it's already half the
>way to go).
About HD: is there a way to do swap on demand to a partition? A
On Thu, Nov 04, 1999 at 09:30:56AM +, Austin Donnelly <[EMAIL PROTECTED]> wrote:
> Look, you're all missing the point.
No, since we are not talking about the current situation...
> Gimp does it's own tile swapping not because it wants to control the
> layout on disk. As some of you have poi
On Wed, Nov 03, 1999 at 05:40:03PM -0600, Tim Mooney
<[EMAIL PROTECTED]> wrote:
> As far as I know, most Unix and Unix-like OSes will generally try give you
> the space you're requesting as a contiguous chunk. In the case of files like
> a (e.g.) 40 Meg swap-file for the gimp, that may not be po
In regard to: Re: Re: Tile Cache Size, Marc Lehmann said (at 1:05am on Nov...:
>On Mon, Nov 01, 1999 at 08:04:39PM -0600, Tim Mooney
><[EMAIL PROTECTED]> wrote:
>> Wouldn't the situation be even worse, then, if we're going through the
>> filesystem and there&#x
On Mon, Nov 01, 1999 at 08:04:39PM -0600, Tim Mooney
<[EMAIL PROTECTED]> wrote:
> Wouldn't the situation be even worse, then, if we're going through the
> filesystem and there's "average" fragmentation? You seem to be assuming that
> the filesystem allocation will be contiguous (or at least clos
In regard to: Re: Re: Tile Cache Size, Marc Lehmann said (at 10:35pm on Nov...:
>On Mon, Nov 01, 1999 at 10:22:08PM +0100, "Guillermo S. Romero / Familia Romero"
><[EMAIL PROTECTED]> wrote:
>> Yes, but Gimp swaps to files, while system normally swaps to partition,
>This is totally wrong in the case of Linux (ok, not unix, but even more
>common).
Hehehe, then how will you describe my experiences with other non-unix
systems? Do not waste your time trying: pathetic and noisy just to start.
>With a better layout, gimp swapping should be able to succeed virtua
On Mon, Nov 01, 1999 at 10:22:08PM +0100, "Guillermo S. Romero / Familia Romero"
<[EMAIL PROTECTED]> wrote:
> Yes, but Gimp swaps to files, while system normally swaps to partition, and
> if the admin is smart, to a fast disk which main (unique?) task is swapping,
> maybe even sharing swap among
>This is not necissarily true. The System-Swap routine is optimized for
>arbitrary data. Gimp organizes its image-data in tiles and may perform
>better in swapping those tiles, since they are a very special data-structure.
Nor false.
>So the swapping routines could be optimized specially for tho
On Mon, Nov 01, 1999 at 10:02:29PM +0100, Simon Budig <[EMAIL PROTECTED]> wrote:
> So the swapping routines could be optimized specially for those data
> (I have no idea if this is done currently) and perform better than the
> systems routine.
Last time I looked, swap space in gimp is managed on
On Mon, Nov 01, 1999 at 09:41:17PM +0100, "Guillermo S. Romero / Familia Romero"
<[EMAIL PROTECTED]> wrote:
> Why I say that? Becuase Unix swap (I suppose to a partition, not to a file)
> will be better than Gimp swap
This is totally wrong in the case of Linux (ok, not unix, but even more
common
On Mon, Nov 01, 1999 at 12:05:26PM -0800, Tuomas Kuosmanen <[EMAIL PROTECTED]> wrote:
>
> But at least tell me what _I_ should use to avoid excess swapping and even
It´s easy... try to detect the pysical memory (on common platforms). Then
use getrlimit to find out how much virtual memory we are
Guillermo S. Romero / Familia Romero ([EMAIL PROTECTED]) wrote:
> Why I say that? Becuase Unix swap (I suppose to a partition, not to a file)
> will be better than Gimp swap. So if you need to swap, use first what the OS
> provides, and then Gimp system (and if NFS, remember to use local /tmp for
>And, Tigert, in your case I'd propose to set it to something like 200MB
>assuming you don't do too much other stuff when working on large images.
>From my experience, tile cache size should be calculated (in a stand alone
workstation, aka system where processes are mainly ow
On Mon, Nov 01, 1999 at 06:58:09PM +0100, Simon Budig wrote:
> Austin Donnelly ([EMAIL PROTECTED]) wrote:
> > Idea: if the size is set to 0, make it mean "guess something good".
> > Out of the box gimp can come with it set to 0, and we just make the
> > algorithm pick something appropriate. That'
Austin Donnelly ([EMAIL PROTECTED]) wrote:
> Idea: if the size is set to 0, make it mean "guess something good".
> Out of the box gimp can come with it set to 0, and we just make the
> algorithm pick something appropriate. That's the hard part.
Just to start a discussion: What about trying to de
Idea: if the size is set to 0, make it mean "guess something good".
Out of the box gimp can come with it set to 0, and we just make the
algorithm pick something appropriate. That's the hard part.
Austin
Hi,
Tigert wrote:
>
> Btw, can anyone explain what size should the tile-cache be? I have 256MB of
> ram, and sometimes I need to work with 3000x3000 images, and I love to use
> _lots_ of layers.. This can lead to horrible swapping that can kill X if it
> goes too far. Is the tile-cache a sandbox
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
[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 contr
47 matches
Mail list logo
