RSS/Atom feed Twitter
Site is read-only, email is disabled

Reducing Load Time

This discussion is connected to the gimp-developer-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.

16 of 16 messages available
Toggle history

Please log in to manage your subscriptions.

Reducing Load Time Srihari Sriraman 05 Dec 16:26
  Reducing Load Time Paka 05 Dec 20:33
   Reducing Load Time Alexandre Prokoudine 05 Dec 22:59
    Reducing Load Time Srihari Sriraman 06 Dec 02:42
    Reducing Load Time Srihari Sriraman 06 Dec 03:03
     Reducing Load Time Srihari Sriraman 06 Dec 12:47
      Reducing Load Time Tobias Oelgarte 06 Dec 14:46
       Reducing Load Time Srihari Sriraman 08 Dec 12:37
        Reducing Load Time Alexandre Prokoudine 08 Dec 12:44
        Reducing Load Time Alexia Death 08 Dec 13:04
         Reducing Load Time Srihari Sriraman 08 Dec 14:56
          Reducing Load Time Rob Antonishen 08 Dec 15:37
         Reducing Load Time Tobias Oelgarte 08 Dec 17:11
         Reducing Load Time Ofnuts 09 Dec 00:38
          Reducing Load Time Alexia Death 09 Dec 09:19
           Reducing Load Time Srihari Sriraman 09 Dec 15:43
Srihari Sriraman
2011-12-05 16:26:10 UTC (over 12 years ago)

Reducing Load Time

Hey,

We all know GIMP takes a small while to load, and it is criminally less than Photoshop or such heavy Softwares... But can we do something to decrease the load time even more? Maybe load it as fast as a plain text editor?

Maybe...

- Bring up the GIMP windows before the loading is complete allowing the user to perform small tasks such as New or Import or Import, while the loading continues in the background, hidden to the user? - Do some *Lazy loading. *Like load a plugin only when the user invokes it?

Paka
2011-12-05 20:33:59 UTC (over 12 years ago)

Reducing Load Time

* Srihari Sriraman [12-05-11 11:27]:

We all know GIMP takes a small while to load, and it is criminally less than Photoshop or such heavy Softwares... But can we do something to decrease the load time even more? Maybe load it as fast as a plain text editor?

perhaps investing in an ssd drive for your operating system and gimp will suffice. Below is the time from requesting load to mouse clicking on the kill button.

15:32 Crash: ~/Documents > time gimp

(gimp:9740): GLib-WARNING **: goption.c:2168: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

real 0m3.919s user 0m1.668s
sys 0m0.158s
15:32 Crash: ~/Documents >

I don't see *any* problem in gimp's load time.

Alexandre Prokoudine
2011-12-05 22:59:25 UTC (over 12 years ago)

Reducing Load Time

On Tue, Dec 6, 2011 at 12:33 AM, Paka wrote:

perhaps investing in an ssd drive for your operating system and gimp will suffice.

Srihari Sriraman
2011-12-06 02:42:29 UTC (over 12 years ago)

Reducing Load Time

Because you don't use extra plug-ins, scripts and, especially, brushes.

So true... Mine takes quite a while... like 10 seconds... I'm thinking 1 to 2 seconds would be good.

How about loading the UI first, and carry out the rest of the loading showing a progress bar at the screen bottom? (Better still, don't show loading progress at all :) )
So the 1-2 second start-up would not show any progress-bar on the splash screen... making the user feel awesome! :)

On Tue, Dec 6, 2011 at 4:29 AM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Tue, Dec 6, 2011 at 12:33 AM, Paka wrote:

perhaps investing in an ssd drive for your operating system and gimp will suffice. Below is the time from requesting load to mouse clicking on the kill button.

15:32 Crash: ~/Documents > time gimp

(gimp:9740): GLib-WARNING **: goption.c:2168: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

real 0m3.919s user 0m1.668s
sys 0m0.158s
15:32 Crash: ~/Documents >

I don't see *any* problem in gimp's load time.

Because you don't use extra plug-ins, scripts and, especially, brushes.

Let me tell about brushes :) GIMP loads them *all* into memory when it starts. So if you have a bunch of bitmap brushes that weight ca. 1GB which isn't so uncommon when you do e.g. photoart, you have to wait for GIMP to finish loading that all *and* you have it using lots of RAM for no good reason, because GIMP doesn't load resources on demand in a smart way (the -d option is a non-smart way).

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Srihari Sriraman
2011-12-06 03:03:15 UTC (over 12 years ago)

Reducing Load Time

Because you don't use extra plug-ins, scripts and, especially, brushes.

So true... Mine takes quite a while... like 10 seconds... I'm thinking 1 to 2 seconds would be good.

How about loading the UI first, and carry out the rest of the loading showing a progress bar at the screen bottom? (Better still, don't show loading progress at all :) )
So the 1-2 second start-up would not show any progress-bar on the splash screen... making the user feel awesome! :)

On Tue, Dec 6, 2011 at 4:29 AM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Tue, Dec 6, 2011 at 12:33 AM, Paka wrote:

perhaps investing in an ssd drive for your operating system and gimp will suffice. Below is the time from requesting load to mouse clicking on the kill button.

15:32 Crash: ~/Documents > time gimp

(gimp:9740): GLib-WARNING **: goption.c:2168: ignoring no-arg, optional-arg or filename flags (8) on option of type 0

real 0m3.919s user 0m1.668s
sys 0m0.158s
15:32 Crash: ~/Documents >

I don't see *any* problem in gimp's load time.

Because you don't use extra plug-ins, scripts and, especially, brushes.

Let me tell about brushes :) GIMP loads them *all* into memory when it starts. So if you have a bunch of bitmap brushes that weight ca. 1GB which isn't so uncommon when you do e.g. photoart, you have to wait for GIMP to finish loading that all *and* you have it using lots of RAM for no good reason, because GIMP doesn't load resources on demand in a smart way (the -d option is a non-smart way).

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Srihari Sriraman
2011-12-06 12:47:56 UTC (over 12 years ago)

Reducing Load Time

How about loading the UI first, and carry out the rest of the loading showing a progress bar at the screen bottom? (Better still, don't show loading progress at all :) )
So the 1-2 second start-up would not show any progress-bar on the splash screen... making the user feel awesome! :)

Regards,

Srihari Sriraman

Tobias Oelgarte
2011-12-06 14:46:08 UTC (over 12 years ago)

Reducing Load Time

I would really prefer that not all brushes would be loaded at start time. Loading the small preview would be ok and could be very fast. But loading a lot of big brushes takes really long and consumes a lot of memory, even so most of them are just grayscale images. Would be really nice if it would only load the brush as you click on it. Then it could use some kind of little cache (e.g. 10 entries) for the last used brushes, so you can quickly switch between them.

My current load time is above 30 Seconds after a cold start (no files from HD in cache). In this scenario it is far away from the default installation that takes only about 5 seconds.

Together with many plugins/addons it takes even longer. I guess that this things should really be loaded at runtime, as needed, and not at the start.

Greetings from
Tobias Oelgarte

Am 06.12.2011 13:47, schrieb Srihari Sriraman:

How about loading the UI first, and carry out the rest of the loading showing a progress bar at the screen bottom? (Better still, don't show loading progress at all :) )
So the 1-2 second start-up would not show any progress-bar on the splash screen... making the user feel awesome! :)

Regards, Srihari Sriraman

Srihari Sriraman
2011-12-08 12:37:56 UTC (over 12 years ago)

Reducing Load Time

Is it possible to implement this change before the release of 2.8? or is it too late?

On Tue, Dec 6, 2011 at 8:16 PM, Tobias Oelgarte < tobias.oelgarte@googlemail.com> wrote:

I would really prefer that not all brushes would be loaded at start time. Loading the small preview would be ok and could be very fast. But loading a lot of big brushes takes really long and consumes a lot of memory, even so most of them are just grayscale images. Would be really nice if it would only load the brush as you click on it. Then it could use some kind of little cache (e.g. 10 entries) for the last used brushes, so you can quickly switch between them.

My current load time is above 30 Seconds after a cold start (no files from HD in cache). In this scenario it is far away from the default installation that takes only about 5 seconds.

Together with many plugins/addons it takes even longer. I guess that this things should really be loaded at runtime, as needed, and not at the start.

Greetings from Tobias Oelgarte

Am 06.12.2011 13:47, schrieb Srihari Sriraman:

How about loading the UI first, and carry out the rest of the loading

showing a progress bar at the screen bottom? (Better still, don't show loading progress at all :) )
So the 1-2 second start-up would not show any progress-bar on the splash screen... making the user feel awesome! :)

Regards, Srihari Sriraman

______________________________**_________________

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/**listinfo/gimp-developer-list

Alexandre Prokoudine
2011-12-08 12:44:38 UTC (over 12 years ago)

Reducing Load Time

On Thu, Dec 8, 2011 at 4:37 PM, Srihari Sriraman wrote:

Is it possible to implement this change before the release of 2.8? or is it too late?

Too late

Alexandre Prokoudine http://libregraphicsworld.org

Alexia Death
2011-12-08 13:04:42 UTC (over 12 years ago)

Reducing Load Time

On Thu, Dec 8, 2011 at 2:37 PM, Srihari Sriraman wrote:

Is it possible to implement this change before the release of 2.8? or is it too late?

The window to get new features into 2.8 closed long ago.

Lazy loading has been on the table for as long as I have been with the project, but it has never been important enough or desired enough to attract a developer to actually implement it and its not a trivial change to do so its actually beneficial. One of the main catches is that for most brushes, to get/generate the preview you need to load it at least once. And once you have loaded it whats the point of dropping it again? Way around it would be to cache previews, but then you would need to manage that collection, keep it in sync with what is and isn't on the disc etc. Whole bunch of complications making the effort spent greater than the benefits. I think last time it came up the recommended solution for these problems was a resource manager that would let users load and unload resource collections on demand and simply limiting the resources loaded at startup. This is something that could even be implemented as a plugin.

Srihari Sriraman
2011-12-08 14:56:30 UTC (over 12 years ago)

Reducing Load Time

Resource manager plugin sounds interesting... Maybe a category in preferences where users can check the resources they want to load on startup...
Cool

On Thu, Dec 8, 2011 at 6:34 PM, Alexia Death wrote:

On Thu, Dec 8, 2011 at 2:37 PM, Srihari Sriraman wrote:

Is it possible to implement this change before the release of 2.8? or is it too late?

The window to get new features into 2.8 closed long ago.

Lazy loading has been on the table for as long as I have been with the project, but it has never been important enough or desired enough to attract a developer to actually implement it and its not a trivial change to do so its actually beneficial. One of the main catches is that for most brushes, to get/generate the preview you need to load it at least once. And once you have loaded it whats the point of dropping it again? Way around it would be to cache previews, but then you would need to manage that collection, keep it in sync with what is and isn't on the disc etc. Whole bunch of complications making the effort spent greater than the benefits. I think last time it came up the recommended solution for these problems was a resource manager that would let users load and unload resource collections on demand and simply limiting the resources loaded at startup. This is something that could even be implemented as a plugin.

-- --Alexia

Rob Antonishen
2011-12-08 15:37:22 UTC (over 12 years ago)

Reducing Load Time

There is the python plugin GURM http://registry.gimp.org/node/13473

I use the default resource set, and then GURM to dynamically activate brush/gradient/pattern/palettes once gimp is running. It also does scripts but I do not use that feature. It can't do plugins as there is no way through the exposed API to reload plugins. I'm hoping that Gimp 2.8 will provide an API to also set tags on resources, then I will modify GURM to not just load the resource sets but also associated resource tags....

-Rob A>

On Thu, Dec 8, 2011 at 9:56 AM, Srihari Sriraman wrote:

Resource manager plugin sounds interesting... Maybe a category in preferences where users can check the resources they want to load on startup...
Cool

On Thu, Dec 8, 2011 at 6:34 PM, Alexia Death wrote:

On Thu, Dec 8, 2011 at 2:37 PM, Srihari Sriraman wrote:

Is it possible to implement this change before the release of 2.8? or is it too late?

The window to get new features into 2.8 closed long ago.

Lazy loading has been on the table for as long as I have been with the project, but it has never been important enough or desired enough to attract a developer to actually implement it and its not a trivial change to do so its actually beneficial. One of the main catches is that for most brushes, to get/generate the preview you need to load it at least once. And once you have loaded it whats the point of dropping it again? Way around it would be to cache previews, but then you would need to manage that collection, keep it in sync with what is and isn't on the disc etc. Whole bunch of complications making the effort spent greater than the benefits. I think last time it came up the recommended solution for these problems was a resource manager that would let users load and unload resource collections on demand and simply limiting the resources loaded at startup. This is something that could even be implemented as a plugin.

-- --Alexia

--
*
*
*Regards,
*
*Srihari Sriraman
*

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Tobias Oelgarte
2011-12-08 17:11:14 UTC (over 12 years ago)

Reducing Load Time

Am 08.12.2011 14:04, schrieb Alexia Death:

On Thu, Dec 8, 2011 at 2:37 PM, Srihari Sriraman wrote:

Is it possible to implement this change before the release of 2.8? or is it too late?

The window to get new features into 2.8 closed long ago.

Lazy loading has been on the table for as long as I have been with the project, but it has never been important enough or desired enough to attract a developer to actually implement it and its not a trivial change to do so its actually beneficial. One of the main catches is that for most brushes, to get/generate the preview you need to load it at least once. And once you have loaded it whats the point of dropping it again? Way around it would be to cache previews, but then you would need to manage that collection, keep it in sync with what is and isn't on the disc etc. Whole bunch of complications making the effort spent greater than the benefits. I think last time it came up the recommended solution for these problems was a resource manager that would let users load and unload resource collections on demand and simply limiting the resources loaded at startup. This is something that could even be implemented as a plugin.

It doesn't have to use a cache for the previews. Like thumbnails of big images the previews can be loaded rather fast. Encoding the whole brushes, which are usually much larger as the previews, is the time and RAM consuming issue.

But even implementing a cache can't be such an hard task. To check if some files are present or not is quickly done and the previews could indicate that the brush files are missing or they would be just removed/hidden. Quite an easy task to do, which is very much comparable to the "recent files" feature.

Greetings from Tobias Oelgarte

Ofnuts
2011-12-09 00:38:10 UTC (over 12 years ago)

Reducing Load Time

On 12/08/2011 02:04 PM, Alexia Death wrote:

On Thu, Dec 8, 2011 at 2:37 PM, Srihari Sriraman wrote:

Is it possible to implement this change before the release of 2.8? or is it too late?

The window to get new features into 2.8 closed long ago.

Lazy loading has been on the table for as long as I have been with the project, but it has never been important enough or desired enough to attract a developer to actually implement it and its not a trivial change to do so its actually beneficial. One of the main catches is that for most brushes, to get/generate the preview you need to load it at least once. And once you have loaded it whats the point of dropping it again?

IMHO the problem is more with the current single-level display of brushes. Gimp will look in subfolders of the declared folders, but it should allow some hierarchical navigation as well. The current interface must have been designed when the designers thought that 100 brushes would be plenty.. They were right on one point: the resulting interface is very hard to use with more than 100 brushes.

And once you have a hierarchical navigation, you only need to load the brushes from the current brush folder.

Alexia Death
2011-12-09 09:19:14 UTC (over 12 years ago)

Reducing Load Time

On Fri, Dec 9, 2011 at 2:38 AM, Ofnuts wrote:

IMHO the problem is more with the current single-level display of brushes. Gimp will look in subfolders of the declared folders, but it should allow some hierarchical navigation as well. The current interface must have been designed when the designers thought that 100 brushes would be plenty.. They were right on one point: the resulting interface is very hard to use with more than 100 brushes.

Tagging tries to relieve that... There is a very recent patch in master that adds subfolders into the tag cloud. but yeah, it wont cure the loading slowness.

And once you have a hierarchical navigation, you only need to load the brushes from the current brush folder.

You wont get around lazy loading with that. Tool presets have brushes saved in it. What should happen if the preset's brush or gradient or whatever isn't in the current set? What if a script refers to a brush that isn't currently active? Nothing is ever as simple as it looks. There is a lot of interdependency among various bits of gimp and sometimes gimp-s aim for stability complicates matters as well. Gimp has had brush scaling for ages now, and we still have gazillion round brushes, no longer visible in UI but still present, because scripts may make use of them.

Srihari Sriraman
2011-12-09 15:43:48 UTC (over 12 years ago)

Reducing Load Time

Somehow I lost focus on what i had suggested earlier... Lazy loading apart, can we bring up the windows and allow new file creation or importing files,
while the brushes get loaded in the background?

On Fri, Dec 9, 2011 at 2:49 PM, Alexia Death wrote:

On Fri, Dec 9, 2011 at 2:38 AM, Ofnuts wrote:

IMHO the problem is more with the current single-level display of

brushes.

Gimp will look in subfolders of the declared folders, but it should allow some hierarchical navigation as well. The current interface must have

been

designed when the designers thought that 100 brushes would be plenty..

They

were right on one point: the resulting interface is very hard to use with more than 100 brushes.

Tagging tries to relieve that... There is a very recent patch in master that adds subfolders into the tag cloud. but yeah, it wont cure the loading slowness.

And once you have a hierarchical navigation, you only need to load the brushes from the current brush folder.

You wont get around lazy loading with that. Tool presets have brushes saved in it. What should happen if the preset's brush or gradient or whatever isn't in the current set? What if a script refers to a brush that isn't currently active? Nothing is ever as simple as it looks. There is a lot of interdependency among various bits of gimp and sometimes gimp-s aim for stability complicates matters as well. Gimp has had brush scaling for ages now, and we still have gazillion round brushes, no longer visible in UI but still present, because scripts may make use of them.
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list