The GIMP's modules for OS/2 need some extra handling.
It's copied into the 3-4 modules C files and it's also not
updated. I want to clean up this code.
I suggest to create a new file called modregister.c and put
all the "register" things there. Modules have to link the new file.
The will be
On Monday, 8 Nov 1999, Asbjoern Pettersen wrote:
The GIMP's modules for OS/2 need some extra handling.
It's copied into the 3-4 modules C files and it's also not
updated. I want to clean up this code.
The same problem was occurring on Solaris2. Yosh has now tweaked some
of the libtool
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
On Wed, Nov 03, 1999 at 08:20:14AM +0100, Martin Treusch von Buttlar [EMAIL PROTECTED]
wrote:
There is currently only a windows 95 environment for this and I am
Is it commercial (bd ;)?
The bottom of ru should be on the same y-pos as the baseline of Äq.
While I think it would be a
On Wed, Nov 03, 1999 at 10:47:48AM +0100, Uwe Koloska [EMAIL PROTECTED]
wrote:
Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally
systems without thread support) because it needs the threaded version of
My very own personal opinion on this is:
- either make gimp
On Wed, Nov 03, 1999 at 11:07:32AM +0100, Uwe Koloska [EMAIL PROTECTED]
wrote:
I don't know anything about the actual CVS-release but with 1.1.10 I have to
disable nls-support, because there are so many doubled menus (some german, some
english). Maybe it's because I'm using a libc5 based
On Sun, Nov 07, 1999 at 08:39:51PM +0100, [EMAIL PROTECTED] wrote:
This sounds interesting (explain!).. how can i18n lead to segfaults?
Not again Marc, we have had this discussion before
You told me that all my menus would be shown twice (which was a problem on
your machine only).
On Wed, Nov 03, 1999 at 10:20:37AM +0100, Michael Natterer [EMAIL PROTECTED]
wrote:
I was (or at least tried to be) very careful not to change any external
interface (which I suppose you mean by "cause other changes as well")
with the context changes because playing around with the PDB
Marc Lehmann [EMAIL PROTECTED] writes:
I must have misunderstood your problem: why do you want to know the ascent or
the descent of a given string?
AFAIUTP, it isn't possible for a given text layer to tell where the baseline
is. So it isn't possible for different text layers to line up.
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 Mon, 8 Nov 1999, Marc Lehmann wrote:
I must have misunderstood your problem: why do you want to know the ascent or
the descent of a given string?
I've only been following this thread on-and-off so please forgive any
ignorance :-)
One problem with the current system that I encountered was
On Mon, 8 Nov 1999, Marc Lehmann wrote:
The ascent and descent are stupidly reported for the font, not the
given string.
Ok, then I'd say this is a very bad bug ;) I'd suggest fixing it by not
removing any space from the text layer / the tetx string returned by
gimp_text.
Or add a new
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
On Mon, 8 Nov 1999 17:13:08 + (GMT), Austin Donnelly wrote:
The GIMP's modules for OS/2 need some extra handling.
It's copied into the 3-4 modules C files and it's also not
updated. I want to clean up this code.
The same problem was occurring on Solaris2. Yosh has now tweaked some
of
22 matches
Mail list logo