Anybody looking forward to GIMP-3.0?

On open-source forums they write that it is terribly fat, slow and laggy. It starts much longer than 2.10.

There are no localization files in appimage for x86_64 (I checked several different languages - there are none). Does anyone know if this is intended?

In Ubuntu 22.04, launching from AppImage is terribly glitchy. I tried changing the design theme - crash, then I changed the font scale - it started to crash whenever I tried to change the design theme parameters. I went through the dialogs - crash. The first cropping of the image went as usual, but in the subsequent ones it started to glitch, instead of cropping it just marks the layer, but does not throw back the borders. It is doubtful that it can be used in work in this form.
Most likely I will freeze and lock 2.10.
 
GIMP is the slowest starting program I have seen. Maybe there are slower but GIMP is my "favorite". I don't know what incredibly important initialization is made to excuse this delay. And this is not version 0.9.beta, waiting for improvement. I bet it can start 20 times faster and do the same job.
 
More important than the startup time is that making an alteration on a GIMP layer is (justifiably) slower if you have non-destructive filters on it. For example, if you want to edit a mask of a layer which has effects applied to it and that layer is inside a group with its own effects, those have to be re-applied on canvas every time you change the mask. It's understandable why this happens and there's not much you can do other than to speed up the effect rendering and algorithms, it's just something to note if you want to use non-destructive editing for everything.
 
The startup time is likely to a major part made up of scanning for plugins. That would make the time proportional to the number of plugins installed.

Having GIMP in a flatpak or snap or apptainer doesn't help matters as special handling is required to give it access to plugins outside the container.
 
cracauer@ said:
The startup time is likely to a major part made up of scanning for plugins. That would make the time proportional to the number of plugins installed.
Click to expand...
This is not an excuse for slowness. If the program is written is Java then the slowness is clear. Otherwise it is bad programming. I have not tested the latest version - maybe it is better. Old versions of VLC player were similar but later it was improved.
 
6502 said:
This is not an excuse for slowness. If the program is written is Java then the slowness is clear. Otherwise it is bad programming. I have not tested the latest version - maybe it is better. Old versions of VLC player were similar but later it was improved.
Click to expand...

Scanning a lot of plugins takes time and involves a lot of open, read and directory listing system calls. You can skip it if you detect that nothing changed since last time, but that isn't trivial to get bulletproof.

Audio software has the same issue but much worse.
 
6502 said:
This is not an excuse for slowness. If the program is written is Java then the slowness is clear. Otherwise it is bad programming. I have not tested the latest version - maybe it is better. Old versions of VLC player were similar but later it was improved.
Click to expand...
Java isn't nearly as slow as people think it is, the virtual machine is designed for performance in comparison to other language VMs, I'd guess that is also why it's designed to use more memory than others, even .NET. A lot of times the problem comes from the old OOP developer overengineering mentality.
Same thing happens to the complaints of Java's boilerplate: Java's boilerplate itself is fine and not much different from C++, most of the boilerplate people complain about comes from the same OOP factorywhatever mentalities that are used in the industry.

Some people also point out Minecraft's bad performance, but that performance comes from how the game is programmed and not Java itself, as you can improve performance to a very significant level by merely adding some performance mods like Sodium which are written in the same language and are bytecode.
 
They also write...
1. Oh, and sane doesn't work in gimp 3 - and I often use the scanner.
2. CSS also eats up the processor like crazy.
3. On Windows, GIMP 3.0 now opens windows with a delay of several seconds and with visible black fill for some time.
4. Sane doesn't work. Alas - the best software for the scanner is xsane, it actually contained the plugin for gimp. And alas, this software has not been ported to gtk3, and its active support has long been absent.
 
USerID said:
They also write...
1. Oh, and sane doesn't work in gimp 3 - and I often use the scanner.
2. CSS also eats up the processor like crazy.
3. On Windows, GIMP 3.0 now opens windows with a delay of several seconds and with visible black fill for some time.
4. Sane doesn't work. Alas - the best software for the scanner is xsane, it actually contained the plugin for gimp. And alas, this software has not been ported to gtk3, and its active support has long been absent.
Click to expand...

What platform and packaging system does sane refuse to work in?
 
You must log in or register to reply here.
Back
Top