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
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
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 WIL
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
compl
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
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 y
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,
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
[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
24 matches
Mail list logo
