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
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?
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
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
19 matches
Mail list logo