On Thu, 18 Nov 2004 12:03:21 -0200, Joao S. O. Bueno Calligaris Hi...
So, my point is that for getting the best possible performance a
realtime preview of any tool not able to do it's job in realtime
would have to be applyed after the crop and scale in this diagram -
and them, the Image Data
Hi,
while we are discussing this. Would anyone object if we changed the
default tile cache size from 64MB to 128MB? Memory is becoming cheap
these days and IMO it is reasonable to adapt the default value from
time to time.
Sven
___
Gimp-developer
David Neary wrote:
Hi Sven
Sven Neumann wrote:
while we are discussing this. Would anyone object if we changed the
default tile cache size from 64MB to 128MB? Memory is becoming cheap
these days and IMO it is reasonable to adapt the default value from
time to time.
I think that's reasonable.
More
On Sun, 14 Nov 2004 23:08:08 -0200, Joao S. O. Bueno Calligaris The
point here is no news for us.
The GIMP is not as fast as it can possibly be one day for large
images.
I've put some thought on it these days - (just thinking, no code), and
one idea that came by. What I intend with writing
Hi,
Sven Neumann wrote:
Hi,
while we are discussing this. Would anyone object if we changed the
default tile cache size from 64MB to 128MB? Memory is becoming cheap
these days and IMO it is reasonable to adapt the default value from
time to time.
Wouldn't it make sense to to check to amount of
On Tue, Nov 16, 2004 at 02:27:17PM +0100, Michael Schumacher wrote:
More important than a specific default value is IMO that the docs
describe exactly what this setting is for and provide some reasonable
examples for different setups.
Currently, a user can't really figure out what this
Carol Spears wrote:
On Tue, Nov 16, 2004 at 02:27:17PM +0100, Michael Schumacher wrote:
More important than a specific default value is IMO that the docs
describe exactly what this setting is for and provide some reasonable
examples for different setups.
Currently, a user can't really figure
On Tue, Nov 16, 2004 at 06:52:27PM +0100, Michael Schumacher wrote:
Carol Spears wrote:
http://www.gimp.org/unix/howtos/tile_cache.html
This is part of the problem - some useful information is kept from users
of other platforms.
i made this problem.
when i was
Michael Schumacher wrote:
Currently, a user can't really figure out what this setting does, at
least by reading the docs.
http://www.gimp.org/unix/howtos/tile_cache.html
This is part of the problem - some useful information is kept from users
of other platforms.
[
On Tue, 16 Nov 2004, Sven Neumann wrote:
Date: Tue, 16 Nov 2004 12:07:31 +0100
From: Sven Neumann [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] comparing gimp speed
Hi,
while we are discussing this. Would anyone object if we changed the
default tile cache size
Hi,
Soren Hauberg [EMAIL PROTECTED] writes:
Wouldn't it make sense to to check to amount of memory available on
the machine before suggestion the tile cache size?
Haven't we discussed this like 200 times already?
A default tile cache on 128MB wouldn't be nice on a 128MB system (I
guess).
Hi,
Michael Schumacher [EMAIL PROTECTED] writes:
At least it could become part of the gimp docs and be translated -
just like the man pages.
The man pages are translated? Since when?
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
Hi,
Alan Horkan wrote:
Would it be difficult to query the operating system and to automatically
set the tile cache size to some percentage (50%?) of available RAM?
In a portable way, impossible. Having different routines for each
platform, perhaps. It would be nice if glib did something like
Sven Neumann wrote:
Hi,
Michael Schumacher [EMAIL PROTECTED] writes:
At least it could become part of the gimp docs and be translated -
just like the man pages.
The man pages are translated? Since when?
No, they should be - and it would be good to have them in the docs, as
almost no one seems
Hi,
Michael Schumacher [EMAIL PROTECTED] writes:
No, they should be - and it would be good to have them in the docs, as
almost no one seems to know about man pages anymore these days.
We could consider this for the next release. The gimprc manpage is
generated. Since most of these strings are
Hi,
Michael Schumacher [EMAIL PROTECTED] writes:
and it would be good to have them in the docs, as almost no one
seems to know about man pages anymore these days.
The GIMP man-pages are online at
http://www.gimp.org/unix/man-gimp-2.0.html
http://www.gimp.org/unix/man-gimprc-2.0.html
On Thursday 11 November 2004 20:41, Sven Neumann wrote:
Hi,
Dov Kruger [EMAIL PROTECTED] writes:
I noticed that gimp is very slow for large images compared with
Photoshop. We were recently processing some 500Mb images, and on
a fast machine with 2Gb, gimp is crawling along, while on a
On 13.11.2004, at 08:48, Manish Singh wrote:
shm is a special case. I'm talking about allocating highmem
segments.
So, what is the userspace API for this?
AFAIK there's no direct userspace helper to address highmem
segments; one can only map them in the Linux kernel and
provide them to userspace
On 13.11.2004, at 07:45, Laxminarayan Kamath wrote:
t's a whole bunch of contortions, and all pointless since amd64
hardware is competitively priced these days.
please dont concentrate only on those who can change pcs like shirts,
concentrate on us poor people too. ;)
Actually my focus is on
Laxminarayan Kamath wrote:
Manish Singh
[EMAIL PROTECTED] to Daniel, Sven, gimp-developer
On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote:
...
t's a whole bunch of contortions, and all pointless since amd64
hardware is competitively priced these days.
please dont
What about making gimp do a benchmaking on the machine and then let it
automatically decide what method 2 use for that swapping/ tiling
stuff.. Hey, now dont beat me. I confess i actually know none of the
stuff
--
Laxminarayan Kamath Ammembal
MithraKoota, Bhoja Rao Lane,
Mangalore 575003
(+91)
On Fri, Nov 12, 2004 at 04:49:03PM +0530, Laxminarayan Kamath wrote:
What about making gimp do a benchmaking on the machine and then let it
automatically decide what method 2 use for that swapping/ tiling
stuff.. Hey, now dont beat me. I confess i actually know none of the
stuff
Hi,
Daniel Egger wrote:
It would be really cool if the pixel data addressing was pluggable so
one could easily write a different storage backend. On top of my head
there would be several schemes I'd like to try:
- A simple linear memory segment with COW for new layers
- dito but with RLE
Hi,
Daniel Egger [EMAIL PROTECTED] writes:
Of course there's also a physical limit and you would need a 64bit
CPU in order to use more than 4GB.
Not necessarily, there some CPU extensions for x86 CPUs which
allow larger memory sizes by using extra large pages (more
overhead) or providing
On 12.11.2004, at 15:51, Sven Neumann wrote:
That allows you to stuff more RAM into your box but you can still only
give up to 4GB to a single process simply because you cannot handle
more than 4GB in a 32bit address space.
You can, but not using the typical APIs. This is pretty important
for
On Fri, 12 Nov 2004 11:34:35 +0100, Daniel Egger [EMAIL PROTECTED] wrote:
It would be really cool if the pixel data addressing was pluggable so
one could easily write a different storage backend. On top of my head
there would be several schemes I'd like to try:
- A simple linear memory
Manish Singh
[EMAIL PROTECTED] to Daniel, Sven, gimp-developer
On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote:
...
t's a whole bunch of contortions, and all pointless since amd64
hardware is competitively priced these days.
please dont concentrate only on those who
On Sat, Nov 13, 2004 at 12:15:22PM +0530, Laxminarayan Kamath wrote:
Manish Singh
[EMAIL PROTECTED] to Daniel, Sven, gimp-developer
On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote:
...
t's a whole bunch of contortions, and all pointless since amd64
hardware is
On Fri, Nov 12, 2004 at 08:11:54PM +0100, Daniel Egger wrote:
On 12.11.2004, at 18:51, Manish Singh wrote:
You can, but not using the typical APIs. This is pretty important
for database stuff
Whose use case is very different than GIMP's. And you do use the
typical
APIs, but the user
I noticed that gimp is very slow for large images compared with
Photoshop. We were recently processing some 500Mb images, and on a fast
machine with 2Gb, gimp is crawling along, while on a slower machine with
only 512 Mb, photoshop is considerably faster. I attributed it to a
massive amount of
Hi,
Dov Kruger [EMAIL PROTECTED] writes:
I noticed that gimp is very slow for large images compared with
Photoshop. We were recently processing some 500Mb images, and on a fast
machine with 2Gb, gimp is crawling along, while on a slower machine with
only 512 Mb, photoshop is considerably
31 matches
Mail list logo
