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 Imag
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
ht
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
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,
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
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]
http:/
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
> gues
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
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 othe
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.
wh
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 out
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 t
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 memo
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 w
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 i
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.
Cheers,
Dave.
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 mai
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, whil
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 havin
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 (
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 don
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
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
> >hardw
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
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 does have to setup the shmfs on their own. And then
you have to select
On Fri, Nov 12, 2004 at 06:08:17PM +0100, Daniel Egger wrote:
> 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.
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
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 datab
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 pr
On 12.11.2004, at 13:12, Sven Neumann wrote:
The operating system imposes a limit on the maximum amount of memory
that can be allocated by a process. IIRC the limit is 3GB on Linux.
Typically the splitting point (user/kernel and peripheral memory)
would be 2:2, but there is a way to easily get 3:1
Date: Fri, 12 Nov 2004 14:23:49 +0100
From: Tino Schwarze <[EMAIL PROTECTED]>
Hi,
On Fri, Nov 12, 2004 at 01:12:33PM +0100, Sven Neumann wrote:
> > [1] Working ain't gonna be fun - I once had an A1 poster at 300 dpi on
> > an 6 GB machine and GIMP's swap grow as large as anothe
Hi,
On Fri, Nov 12, 2004 at 01:12:33PM +0100, Sven Neumann wrote:
> > [1] Working ain't gonna be fun - I once had an A1 poster at 300 dpi on
> > an 6 GB machine and GIMP's swap grow as large as another 6 GB since GIMP
> > didn't seem to be able to use more than 2 or 3 GB of memory altogether.
> >
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,
Tino Schwarze <[EMAIL PROTECTED]> writes:
> [1] Working ain't gonna be fun - I once had an A1 poster at 300 dpi on
> an 6 GB machine and GIMP's swap grow as large as another 6 GB since GIMP
> didn't seem to be able to use more than 2 or 3 GB of memory altogether.
> (Is there a known limitatio
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>
Unfortu
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)
Hi there,
On Fri, Nov 12, 2004 at 02:13:46AM +0200, Steve Stavropoulos wrote:
> > The most important thing to do is balance your tile cache setting, as
> > you've already found. You want it large enough that GIMP doesn't have
> > to use its own virtual memory, but not so large that the OS has to
On 12.11.2004, at 01:13, Steve Stavropoulos wrote:
If the OS has better virtual memory than what available to gimp, then
you would want to use that one. In Linux, I think in most cases, you
would want to use the (often in multiple disks) swap partitions/files
available to the OS.
GIMP does tile sw
On Thu, 11 Nov 2004 23:16:49 +, Alastair M. Robinson wrote:
>
> The most important thing to do is balance your tile cache setting, as
> you've already found. You want it large enough that GIMP doesn't have
> to use its own virtual memory, but not so large that the OS has to use
> virtual memor
Hi,
Dov Kruger wrote:
Granted, because you are editing the image, not just displaying it,
there has to be some slowdown, but I wondered if there is any way I can
tweak gimp, do I somehow have it massively de-optimized. When I first
set up gimp-2.0, I tried both 128 and 512 Mb tile cache sizes. 512
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 considerabl
On Thu, Nov 11, 2004 at 03:28:14PM -0500, Dov Kruger wrote:
> 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
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 wor
43 matches
Mail list logo