GIMP Punts Painting Off To Separate Thread

[phoronix]

Phoronix: GIMP Punts Painting Off To Separate Thread

As a long overdue move, the GIMP image manipulation program now has support for moving the painting process off to a separate CPU thread...

http://www.phoronix.com/scan.php?page=news_item&px=GIMP-Gets-Painting-Thread

[cen1]

So... why is it so hard to thread this stuff if it only took a few 100 of lines of code? Don't even get me started with GNOME desktop which apparently runs even the extensions in the same thread! No wonder my desktop drops to 5FPS when I press superkey, can't even handle the animation.

I am switching to KDE in the immediate future, this is a complete joke.

[Serafean]

So... why is it so hard to thread this stuff if it only took a few 100 of lines of code? Don't even get me started with GNOME desktop which apparently runs even the extensions in the same thread! No wonder my desktop drops to 5FPS when I press superkey, can't even handle the animation.

I am switching to KDE in the immediate future, this is a complete joke.

The fact that something takes 100 lines of code tells you nothing about the necessary mental processing behind them.

[cen1]

The fact that something takes 100 lines of code tells you nothing about the necessary mental processing behind them.

We are in year 2018 with CPUs having from 8 to 32 threads, there is no excause why GUI and work threads are not seperate already.

Even a stupid Qt desktop app I wrote 3 years ago has all work seperated in own threads, connected to UI with signals and slots mechanism. Qt has this excellent support out of the box.

[You-]

This step might have been 100 lines but you do not know how much work it required before this.

I would suggest that a "stupid" desktop app is easier to write with separated threads than rewiring a codebase that has 20 years of history, during which there could be many assumptions expecting a single thread.

Changing to KDE wont stop you from using the GIMP when needed (and you can use the alternatives on Gnome too).

[kaprikawn]

Moar freds? Rewrite in teh Rust...fearless parallelism

[discordian]

***very very slow clapping***
Of course these issues only come up after having a fix, before that you will be crucified for complaining about sluggish behavior.

I guess in 20 years, Gnome will finally admit that things are crappy without a scenegraph and server-side rendering.

[Naquatis]

I never had any problems while painting in Gimp with all pads up to Cintiq. I also tested KDE Plasma and to some reason I was quickly back on XFCE. No idea why people are so nasty with Gnome. Go write your own DE and stop screaming about people who really do stuff for the community.

[ciplogic]

So... why is it so hard to thread this stuff if it only took a few 100 of lines of code? Don't even get me started with GNOME desktop which apparently runs even the extensions in the same thread! No wonder my desktop drops to 5FPS when I press superkey, can't even handle the animation.

I am switching to KDE in the immediate future, this is a complete joke.

It looks to me that only brushes are painted off-thread. In fact most operations are multithreaded by the inner framework, and this code moves only drawing brushes outside of the MT.

But even so, what is the point of bashing Gnome for this?

Your logic is like this:
1. One GTK app is poorly written (which it isn't).

2. This means that a DE is poorly written because is GTK

Do you even logic?

[ciplogic]

And if you don't believe it is multi-threaded:

https://ccm.net/faq/12186-gimp-select-the-number-of-processors-to-be-used