>I was used to adjusting photoshop to prevent it swapping, and tried to do
>that with GIMP, the above figures were based on my idea that X wanted 30
>megs and gimp seemed to want about 10 or so, leaving about 20 left for the
>image. All wrong, terribly wrong. I set the cache to 30 megs last nigh
On 7 Jun, Sven Neumann wrote:
> As profiling the Gimp shows, there's the need and room for
> optimization. Marc and Daniel did work on this last weekend
> and hopefully we will soon see those changes in CVS.
I'd be very glad I you could apply this patches I'll send them to
you soon
-
or that matter). It seems a bit extravagant to spend
some 200UKP or so on a machine when I'm surrounded by them..
> 64megs is a small amount of ram for images that heavy.
> im surprised your getting decent performance from
> photoshop.
It is a small amount, now I've gotten over the
Hi,
> at 4k x 3k for most things you do see the line comming
> down. its slow for hue/sat/lightness adjustments, and
> fastest for curves. i may try this on windows, but i
> think some of the others on this list have already
> beaten that horse enough.
Someone already mentioned it, but I want to
runs fine on most macs
and theres always mac on linux, which probably runs
photoshop, meaning you can easily have both. if you
try this, please tell me (and/or the group) how it
works.
64megs is a small amount of ram for images that heavy.
im surprised your getting decent performance from
pho
Hyperborean wrote:
>
> Could it be that Photoshop does the previews only on the
> visible pixels?
I'm with George on this one! Pre-vue mode should be visible pixels
only.
--
Jon Winters http://www.obscurasite.com/jon/
"Everybody Loves The GIMP!"
http://www.gimp.org/
Andy Thomas wrote:
> What version of gimp are you using? The recent CVS versions had a real
> bug in the updating of previews when using the levels/curves stuff.
On the advice of Andy and others I disabled the layer pre-vue images and
things speeded up quite a bit. (they also mentioned this is
ng on
okay would finish it.
-George
-Original Message-
From: Jon Winters <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Tue, 6 Jun 2000 10:03:22 -0500 (CDT)
Subject: Re: Performance of Gimp vs. photoshop for large images (fwd)
>
> Hi,
>
> I'm forwarding this f
Scavenging the mail folder uncovered Jon Winters's letter:
>
> I'm forwarding this from gimp-user for anyone who is not on that list.
> There was a question regarding performance and configuration but I can't
> seem to get Gimp to outperform Photoshop.
>
> TIA
Hi,
I'm forwarding this from gimp-user for anyone who is not on that list.
There was a question regarding performance and configuration but I can't
seem to get Gimp to outperform Photoshop.
TIA for any configuration tweeks that may help me. (so far the only thing
i've done is
On 4 Feb, Raphael Quinet wrote:
> I wouldn't be too sure about that. On a system that I was previously
> administering (students' network at the university), I have seen some
> users that were using /var/tmp or /tmp to store their applications
> while they were logged in, and deleted the stuff
On Fri, 04 Feb 2000, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Feb 2000 09:52:30 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said:
> >I disagree. This would only encourage some users to re-compile their
> >own version of the Gimp in a private directory in order to get around
>
On Fri, 4 Feb 2000 09:52:30 +0100 (MET), [EMAIL PROTECTED] (Raphael Quinet) said:
>I disagree. This would only encourage some users to re-compile their
>own version of the Gimp in a private directory in order to get around
>the hardcoded limits.
Frankly, I disagree. Systems where admins are li
On Thu, 03 Feb 2000, Kelly Lynn Martin <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Feb 2000 19:33:31 +0100 (CET), [EMAIL PROTECTED] said:
> > If you have a shared maschine the best would be to let the
> >administrator choose how much memory each user will get because
> >users'll ALWAYS try to get what
On Thu, Feb 03, 2000 at 07:33:31PM +0100, [EMAIL PROTECTED] wrote:
> If you have a shared maschine the best would be to let the
> administrator choose how much memory each user will get because
> users'll ALWAYS try to get what they can even if it makes no
> sense
This is none of our bus
>
> > If you have a shared maschine the best would be to let the
> >administrator choose how much memory each user will get because
> >users'll ALWAYS try to get what they can even if it makes no
> >sense
>
> It might be a good idea to have a compile-time configuration option
> for maximum c
On 03 February, 2000 - Elan Feingold sent me these 0.7K bytes:
> Instead of guessing at fixed amounts, why not:
>
> - Detect how much memory the user has.
> - Pick a reasonable default in terms of percentage (say, 50%).
Gee, that'll work well on our 4G multiuser box..
No answer is
On Thu, 3 Feb 2000 19:33:31 +0100 (CET), [EMAIL PROTECTED] said:
> If you have a shared maschine the best would be to let the
>administrator choose how much memory each user will get because
>users'll ALWAYS try to get what they can even if it makes no
>sense
It might be a good idea to have
On 3 Feb, Raphael Quinet wrote:
> I think that asking the user is the best solution in any case, because
> you can hope that the user has some vague idea of how much memory is
> or will be available on the system he is using (shared or personal
> computer). This will not work in all cases (e.
On 3 Feb, Arcterex wrote:
> I think that this was discussed some time back and the conclusion was
> that if you have 5 users on your system all using gimp and each using
> 50%... well, you see where that could be a problem.
In that case you could adjust the value manually. But bear in mind:
I
means, or even better: a prominent message saying
something like: "please look at the help page for some tips about this
very important option". I think that the majority of Gimp users do
not know what this option means and how it can influence the
performance of the application. I persona
Sven Neumann said...
|
|Shouldn't we increase the default for the tile_cache_size? GIMP was shipped
|with the default of 10MB years ago. Memory is cheap nowadays and I guess we
|can expect the average user to have more RAM available. I'd suggest setting
|it to 32MB.
I'd say go for it. We could a
That way, the default the Gimp ships with will work with all systems, and
> > also on a given system if the user dumps more memory in, the Gimp will
> > automagically have better performance.
>
> I agree that magic numbers are foolish to use, but I do think that the
> method
terms of percentage.
>
> That way, the default the Gimp ships with will work with all systems, and
> also on a given system if the user dumps more memory in, the Gimp will
> automagically have better performance.
I agree that magic numbers are foolish to use, but I do think that the
ven system if the user dumps more memory in, the Gimp will
automagically have better performance.
Just my $0.02,
-Elan
Sven Neumann wrote:
>
> > >You should definitely increase your tile cache size from the default 10mb.
> > >It should help performance.
>
> Shouldn't we increase the default for the tile_cache_size? GIMP was shipped
> with the default of 10MB years ago. Memo
> >You should definitely increase your tile cache size from the default 10mb.
> >It should help performance.
Shouldn't we increase the default for the tile_cache_size? GIMP was shipped
with the default of 10MB years ago. Memory is cheap nowadays and I guess we
can expect th
he default 10mb.
>It should help performance.
Yes, you're right. ;)
However I've noticed that GIMP 1.1.15 has a little bug when changing this
value with the Preferences dialog. It seems to be fixed to 10Mb, the only way
is changing manually gimprc. ;)
I've discovered this bug this
It should help performance.
later,
Andrew Kieschnick
I use SuSE Linux 6.2. I have 128 MB RAM. I use the default values for
tile caching. I have a EIDE IBM 6,4 GB and 10 GB. I use on both a 128
MB partition as swap.
Martin
On Wed, Feb 02, 2000 at 08:13:56AM -0800, Martin Weber wrote:
> Here some performance tests on an Intel Celeron 333 with
On Wed, Feb 02, 2000 at 08:13:56AM -0800, Martin Weber wrote:
> Here some performance tests on an Intel Celeron 333 with 128 MB:
> BMP file, grayscale (8-bit), 1x7500
>
> loading with ImageMagick 5.1.1: 20 min
> loading with GIMP 1.1.15: 10 min
> loading with Photopai
Here some performance tests on an Intel Celeron 333 with 128 MB:
BMP file, grayscale (8-bit), 1x7500
loading with ImageMagick 5.1.1: 20 min
loading with GIMP 1.1.15: 10 min
loading with Photopaint 8: 1 min 39 sec
loading with Photoshop 5: 14 sec
saveing with GIMP 1.1.15: 2 min 25 sec
32 matches
Mail list logo
