RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

strange workaround for slow GIMP start (WinXP) (resent)

This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.
strange workaround for slow GIMP start (WinXP) (resent) Cristian Secar? 26 Jun 18:51
  strange workaround for slow GIMP start (WinXP) (resent) Daniel Hornung 26 Jun 20:06
   strange workaround for slow GIMP start (WinXP) (resent) Cristian Secar? 26 Jun 23:11
    strange workaround for slow GIMP start (WinXP) (resent) Cristian Secar? 26 Jun 23:20
Cristian Secar?
2008-06-26 18:51:01 UTC (over 16 years ago)

strange workaround for slow GIMP start (WinXP) (resent)

(resent message, my original one sent on 24 Jun 2008 21:05:05 +0300 appers it never reaches the gimp-user destination)

After a system reinstall (HDD change) on my HP nc8230 notebook, GIMP was starting painfully slow, almost bloking itself at Fonts-something startup splash screen. This was something new for me, as in the previous WinXP system install GIMP started almost immediately.

Searching a bit I noticed that this happens to be a common issue on many Windows systems, where some have mentioned something about GTK+. This pointed me to the question - what was different in my previous system install related to GTK+ ? Answer - two more GTK+ applications (except for Sylpheed, which does not matter for the subject), Pidgin and GPA. So I installed Pidgin (2.4.2), et voilà, GIMP now starts immediately !

So who knows, maybe this info can be of some help for others too ... (and perhaps for GIMP developers too :)

Cristi

Daniel Hornung
2008-06-26 20:06:08 UTC (over 16 years ago)

strange workaround for slow GIMP start (WinXP) (resent)

On Thursday 26 June 2008, Cristian Secar? wrote:

After a system reinstall (HDD change) on my HP nc8230 notebook, GIMP was starting painfully slow, almost bloking itself at Fonts-something startup splash screen. This was something new for me, as in the previous WinXP system install GIMP started almost immediately.

Searching a bit I noticed that this happens to be a common issue on many Windows systems, where some have mentioned something about GTK+. This pointed me to the question - what was different in my previous system install related to GTK+ ? Answer - two more GTK+ applications (except for Sylpheed, which does not matter for the subject), Pidgin and GPA. So I installed Pidgin (2.4.2), et voilà, GIMP now starts immediately !

So who knows, maybe this info can be of some help for others too ... (and perhaps for GIMP developers too :)

Cristi

Have you tried starting GIMP twice without Pidgin installed? It could simply be that the very first start time takes very long for GIMP because it registers/ cashes all the available fonts and then only has to check for changes on the second and all subsequent starts.

Daniel

Cristian Secar?
2008-06-26 23:11:19 UTC (over 16 years ago)

strange workaround for slow GIMP start (WinXP) (resent)

On Thu, 26 Jun 2008 20:06:08 +0200, Daniel Hornung wrote:

Have you tried starting GIMP twice without Pidgin installed?

Yes, I started it dozen of times, because currently I am working at the Romanian translation and during (say) ~1 hour of translation work I start and close the program almost each and every ~10 minutes in order to check my strings. These days I rarely use GIMP for image processing ...

Cristi

Cristian Secar?
2008-06-26 23:20:02 UTC (over 16 years ago)

strange workaround for slow GIMP start (WinXP) (resent)

On Fri, 27 Jun 2008 00:11:19 +0300, Cristian Secar? wrote:

Have you tried starting GIMP twice without Pidgin installed?

Yes, I started it dozen of times, [...]

... other than that, I am not alone – the internet is full of complains about the program lock at fonts cache splash screen (on Windows). Maybe it is related to some particular method or detail used for Win32 compilation (?).

Cristi