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
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 different
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 seems to do
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]
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 reside???
Nick Lamb ([EMAIL PROTECTED]) wrote:
Loading a large image (*): Wait about 2 mins, loader finishes and now
after a further couple of minutes the image is drawn, however later
performance is slightly faster than in the default case above.
(*) A large image here is one which genuinely WILL
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 over
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
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 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 that
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
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? You
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
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
On Tue, 9 Nov 1999, 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 seems to do is to give you an
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 slower
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
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 10 seconds to
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's "average" fragmentation?
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's the
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 to
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 those
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 virtual
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, and
if the admi
[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
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
26 matches
Mail list logo