Re: gDynText 1.5.0-RC3

[Marco Lamberto]

On Tue, 6 Jun 2000, Federico Di Gregorio wrote:
>hi, i just tried out the new gdyntext and found it really well-done.
>the graphic guy here does not think so... here are some comments from him:
>
>1/ kerning is missing. it would be great to have kerning and the ability
>   to apply it selectively to parts of the text. that is:
>
>   ciao marco -> (i select `o mar' and apply some kerning) -> ciao  m a rco
I know that, however, if I remember well, X11 can't allow kerning control, I
should use t1lib and the freetype libraries for implementing a new font
rendering engine (however this will require to have installed properly those
libraries in order to allow gDynText to run ...).
Is there anyone with a better solution for the "kerning problem"? ;)

>2/ changing font changes the font for all the text. it would be nice to 
>   be able to write with different fonts and apply them selectively, just
>   like the kerning.
>3/ idem for the color and other font attributes...
Eh, eh, I know that!! I'll work on those features as soon as possible! ;))

>he said that will abandon photoshop if only the text in gimp is a little
>better... :)
I'm working (also for you)! ;))
Happy GIMPing,
Marco
-- 
//\/\ Marco (LM) Lamberto
  e-mail:[EMAIL PROTECTED] (remove 'nOsPaMz-')
  The Sunny Spot  -  http://www.geocities.com/Tokyo/1474/

Re: "TAB" to hide toolbox and all dialog windows...

[Seth Burgess]

Jon,

Try hitting "Tab" while in an image.

Seth
[EMAIL PROTECTED]

* Jon Winters ([EMAIL PROTECTED]) [000606 22:27]:
> One of the things that I like about Photoshop is the ability to hit the
> "tab" button on the keyboard and hide everything but the cursor and the
> image.  I use it often when photoshopping and miss it sorely when
> Gimpin'
> 
> If this is already built in please accept my apology and clue me in as
> to how it works.  If not I would like to request it as a feature once
> 1.2 is shipping and the freeze is lifted.
> 
> Thanks in advance and keep up the good work!
> --
> Jon Winters  http://www.obscurasite.com/jon/
> 
>"Everybody Loves The GIMP!"
>   http://www.gimp.org/

"TAB" to hide toolbox and all dialog windows...

[Jon Winters]

One of the things that I like about Photoshop is the ability to hit the
"tab" button on the keyboard and hide everything but the cursor and the
image.  I use it often when photoshopping and miss it sorely when
Gimpin'

If this is already built in please accept my apology and clue me in as
to how it works.  If not I would like to request it as a feature once
1.2 is shipping and the freeze is lifted.

Thanks in advance and keep up the good work!
--
Jon Winters  http://www.obscurasite.com/jon/

   "Everybody Loves The GIMP!"
  http://www.gimp.org/

Re: Performance of Gimp vs. photoshop for large images (fwd)

[Jon Winters]

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/

Re: Performance of Gimp vs. photoshop for large images (fwd)

[Jon Winters]

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 fixed in
the current CVS release)

On a PIII 450, 256MB pc133 RAM, Matrox G400 32MB machine a levels
adjustment on the image takes 4 seconds.  

4 seconds is good but its still twice as long as photoshop.  :-\  

--
Jon Winters  http://www.obscurasite.com/jon/

   "Everybody Loves The GIMP!"
  http://www.gimp.org/

Re[2]: Performance of Gimp vs. photoshop for large images (fwd)

[Hyperborean]

Could it be that Photoshop does the previews only on the
visible pixels?

I don't know how the gimp does this, but it seems to me
that realtime previews on images would best be done on
the set of pixels the user can actually see, i.e. not the
pixels hidden by zooming or panning.  Then clicking 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 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 adjust the tile cache)
> --
> Jon Winters http://www.obscurasite.com/
> 
>"Everybody loves the GIMP!" 
>   http://www.gimp.org/
> 
> -- Forwarded message --
> Date: Tue, 6 Jun 2000 09:52:55 -0500 (CDT)
> From: Jon Winters <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Performance of Gimp vs. photoshop for large images
> 
> 
> Hello all,
> 
> Yesturday I requested that our friend send me a copy of his image so that
> I could try the test on my computer at work. (PIII 400 128MB, Matrox G400,
> WinNT)
> 
> I chose to test with levels because I adjust levels or curves on almost
> every image I edit.
> 
> In Photoshop (v5.0) the redraw after letting go of one of the levels
> sliders was less than two seconds.  (default 'out of the box' photoshop
> configuration)
> 
> In the gimp I was surprised that the performance is indeed terrible.  With
> the tile cache set to 72MB it took 40 seconds.  With the tile cache set to
> 96MB it took 16 seconds.  Moving the tile cache to 128MB (on this 128MB
> machine) knocked it down to 11 seconds.
> 
> Is there some other configuration that I am missing?  
> 
> Years ago I worked as a photographer and our standard image size, in our
> studio using a Leaf Digital Camera Back, was around 100MB.  This kind of
> performance hit would seriously hamper productivity and pretty much force
> the use photoshop.
> 
> Tonight I'll run the same test on my computer at home. (Dual PIII 450,
> 256MB ram, 32MB G400, RedHat 6.2/Helix Gnome)
> 
> Thanks
> --
> Jon Winters http://www.obscurasite.com/
> 
>"Everybody loves the GIMP!" 
>   http://www.gimp.org/
> 
> 
> 
> 

Re: XCF loader for gdk-pixbuf

[Sri Ramkrishna]

Shouldn't this stuff be in writing?  Or is this legal?

sri

On Tue, 6 Jun 2000, Sven Neumann wrote:

> Date: Tue, 06 Jun 2000 00:05:24 +0200
> From: Sven Neumann <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], Phil Schwan <[EMAIL PROTECTED]>,
>  Federico Mena Quintero <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED], [EMAIL PROTECTED],
>  Jens Finke <[EMAIL PROTECTED]>
> Subject: Re: XCF loader for gdk-pixbuf
> 
> Hi,
> 
> Since I've touched app/xcf.[ch] too:
> 
> I hereby give my permission for anyone to use the portions of xcf.c
> that I have written under the terms of the LGPL.
> 
> Please note that we consider to add a thumbnail of the image
> composition to the XCF file format. This might even happen before 
> 1.2...
> 
> 
> Salut, Sven
> 

Re: comments in gifs

[Marc Lehmann]

On Tue, Jun 06, 2000 at 10:24:11AM +0530, Gunjan Kapoor <[EMAIL PROTECTED]> wrote:
> 
> how does one add comments to gif images with scripting ?

By setting the gimp-comment parasite of the image (see docs/parasites.txt)
bafore saving.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |

The undo stack does not record some changes in layer attributes

[Raphael Quinet]

Hi, all!

First, I have to thank Sven for applying my "Script-Fu/Alpha to Logo"
patches.  The modified scripts should work well, but please tell me if
you spot something strange.  I will update the remaining scripts ASAP.

I re-discovered an old problem with these scripts: some operations on
the layers are not recorded on the undo stack.  If I am not mistaken,
these operations are:
- toggling the visibility of a layer,
- toggling its "preserve trans." flag,
- changing its opacity.
This has annoyed me a couple of times when working on some images by
hand, but now the problem is more visible with the "Alpha to Logo"
scripts that are undo-aware.

Some of these scripts set the "preserve trans." flag on the original
layer and apply some operations to it.  If you undo the operations,
you get back to the original image except that the flag is still set.
Running the same script or another script on the image can give a
different result than before, because of this flag.  Some other
scripts toggle the visibility of the layer and keep it in the final
image.  If you undo the script, you are back to the original image
except that the layer is now invisible.  This is not what you would
expect from the "undo" operation...

Here is an easy way to see the problem:
- create a new image
- paint something on the background layer
- paint something more
- make the background layer invisible
- undo
The last paint operation will be undone, but the layer is still
invisible.  This is even more annoying if you change the opacity of a
layer or toggle its "keep trans." flag instead of making it invisible,
because the difference is not always obvious and you could start some
other operations without seeing that the layer behaves differently.

One quick workaround would be to use defensive programming and insert
the following lines in all scripts:
  (gimp-layer-set-visible logo-layer TRUE)
  (gimp-layer-set-opacity logo-layer 100)
  (gimp-layer-set-preserve-trans logo-layer FALSE)
This would ensure that the current layer is in a "sane" state before
starting to process it, but this kludge does not solve the real
problem.

So I have two questions:
- Is there any reason why these three operations are not put on the
  undo stack?
- If there is no good reason for that, could someone tell me how to
  change the code so that it is possible to undo these operations?

-Raphael

Re: Performance of Gimp vs. photoshop for large images (fwd)

[Federico Di Gregorio]

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 for any configuration tweeks that may help me. (so far the only thing
> i've done is adjust the tile cache)

pretty strange. here a g3 notebook with gimp and tile cache set to 128Mb
outperforms a g4 with potoshop! but we are using extremely *BIG* psd files
(>200mb, 200 layers) and linux fs layer is much better than mac, right?

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer   [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
  99.% still isn't 100% but sometimes suffice. -- Me

Re: Performance of Gimp vs. photoshop for large images (fwd)

[Jon Winters]

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 adjust the tile cache)
--
Jon Winters http://www.obscurasite.com/

   "Everybody loves the GIMP!" 
  http://www.gimp.org/

-- Forwarded message --
Date: Tue, 6 Jun 2000 09:52:55 -0500 (CDT)
From: Jon Winters <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Performance of Gimp vs. photoshop for large images


Hello all,

Yesturday I requested that our friend send me a copy of his image so that
I could try the test on my computer at work. (PIII 400 128MB, Matrox G400,
WinNT)

I chose to test with levels because I adjust levels or curves on almost
every image I edit.

In Photoshop (v5.0) the redraw after letting go of one of the levels
sliders was less than two seconds.  (default 'out of the box' photoshop
configuration)

In the gimp I was surprised that the performance is indeed terrible.  With
the tile cache set to 72MB it took 40 seconds.  With the tile cache set to
96MB it took 16 seconds.  Moving the tile cache to 128MB (on this 128MB
machine) knocked it down to 11 seconds.

Is there some other configuration that I am missing?  

Years ago I worked as a photographer and our standard image size, in our
studio using a Leaf Digital Camera Back, was around 100MB.  This kind of
performance hit would seriously hamper productivity and pretty much force
the use photoshop.

Tonight I'll run the same test on my computer at home. (Dual PIII 450,
256MB ram, 32MB G400, RedHat 6.2/Helix Gnome)

Thanks
--
Jon Winters http://www.obscurasite.com/

   "Everybody loves the GIMP!" 
  http://www.gimp.org/

gDynText 1.5.0-RC3

[Marco Lamberto]

A new release is available at:
 
Feedback (expecially for the new user interface) and bug reports are welcome.
Happy GIMPing!
Marco
-- 
//\/\ Marco (LM) Lamberto
  e-mail:[EMAIL PROTECTED] (remove 'nOsPaMz-')
  The Sunny Spot  -  http://www.geocities.com/Tokyo/1474/

Re: Gimp Win32 and -Wall patch

[Tor Lillqvist]

I already tried to answer this from Berlin, but apparently CCC's SMTP
server didn't like me.

Apologies to gimp-developers who couldn't care less for the Windows
version ;-)

Hans Breuer writes:
 > Attached a patch to compile Gimp on Win32 with M$VC again.
 > Could anyone with CVS access apply it, please?

Yes, I will, to the extent it doesn't interfer with other stuff.

 > * */makefile.msc: 
 >   - get the definition of GLIB, GTK etc. out of a single file
 > instead of copy and pasting between all makefiles. This is
 > particular usefull while the CVS version on Win32 is quite
 > broken.

This is in the progress of being taken care of on the gcc side by
using the CVS module "build" which has a makefile snippet in
"build/win32/make.mingw" to be included in other makefiles when
building for mingw with gcc. Your file belongs there.

Actually, I wouldn't mind if somebody else (you) would take over the
maintenance of the MSVC build stuff completely. It is hard enough to
keep the gcc/mingw makefiles up-to-date... (Well, not hard, but
tedious. Yes, I know I really should look closer into getting the
latest-and-greatest auto*, configure and libtool stuff working also
for gcc builds on Win32. It is not necessarily that hard. After my
vacation...)

As for the CVS version of GTk+, it is indeed currently very much
broken on Win32. (Especially after the recent merge of the Pango
stuff. I won't be able to make publicly available any work I'll do on
it until July, as I am leaving for vacation without net access
tomorrow. I will take my laptop and hack on stuff...) For a working
GTk+ on Windows, use the CVS sources as they were before the merge of
the no-flicker branch. (Probably easiest to download the gtk+-src
zipfile from the web page.)

 > * plug-ins/makefile.msc:
 >Change all Plug-Ins to console build - no known drawbacks, 
 >main benefit: reusage of Gimp's console. 

Hmm, but isn't gimp.exe's console window destroyed as soon as it has
started? I don't remember the reason why gimp.exe was changed to be a
console application in the first place. In fact, I have been
considering changing it back to a windowing application to get rid of
the annoying flashing console window at start.

--tml