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?

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.

Reducing Load Time

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! :)

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

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! :)

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

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! :)

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 fromTobias 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! :)

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! :)

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.

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.

Reducing Load Time

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.

Reducing Load Time

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.

Reducing Load Time

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.

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.

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 listgimp-developer-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gimp-developer-list