* 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.

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.

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

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

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.

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

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

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.

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.