Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Gimp 2.8 and 2.9 performance (brush lag)
#1
Question 
Hello. I have been using Gimp for many years (I guess it started with 1.2 or even 1.0 version). Nothing complicated, basic photo edition, low resolution. It was fine. Few Years ago I started to photograph more seriously than before and I decided that I move to Photoshop, mainly for its much bigger tutorials availability and 16-bit tiff support. This year, after my subscription ran out, I decided that I will try to save some $$ and give Gimp another try. I realised, that after some modifications I can use part of my PS experience inside Gimp and it seems 16-bit support is almost there!

After I forced Gimp 2.8 to recognise my tablet I realised I have problems with performance - precisely speaking, brush lag. I am working on quite big files (up to 24mpix) and when I paint on a layer mask using Wacom tablet I have serious brush lag. I realise that my laptop is quite weak (Pentium 2020M, 8GB ram), but Photoshop didn't have this problem, even when working with 16-bit. Is that normal Gimp behaviour?

Second question - I tried Gimp 2.9 - despite 2 core support it is significantly slower (more lag), and after enabling 16-bit depth it is even worse. Is 2.9 slower than 2.8?

Michael

P.S. I tried to disable rulers. It helped -a bit-.
Reply
#2
Well...you might have to go back to using PS. Former use of Gimp 1.2 is really irrevent to present use Wink I go back to Gimp 2.2, things have moved on.

Lets have a few user parameters.

Are you using Windows or Linux? - your user profile lists both.

Quote:After I forced Gimp 2.8 to recognise my tablet

You are using Wacom tablet. Why did you need to force recognition? Can you expand on that? In linux even my ancient Wacom volito is supported. However, could be a problem with Windows.

24 Mp images, big but not that big, my lumix takes 18 Mp and Gimp handles those ok. (my laptop Kubuntu 16.04 is I5 6200U 8 GB memory) but always a but, are you short on disk space?

Quote:Second question - I tried Gimp 2.9 - despite 2 core support it is significantly slower (more lag), and after enabling 16-bit depth it is even worse. Is 2.9 slower than 2.8?

Yes, do not use multiple processors in Gimp 2.9 use Edit -> Preferences -> System Resources set Number of threads to use to 1

Quote:P.S. I tried to disable rulers. It helped -a bit-.

That was fixed back in Gimp 2.8.16 or 2.8.18 - what version of Gimp are you using?
Reply
#3
Probably not: but have you got the 'Smooth Stroke' option active, perhaps ?
Reply
#4
(02-16-2018, 05:28 PM)rich2005 Wrote: Well...you might have to go back to using PS. Former use of Gimp 1.2 is really irrevent to present use Wink I go back to Gimp 2.2, things have moved on.

Lets have a few user parameters.

Are you using Windows or Linux? - your user profile lists both.

My laptop runs Windows 10.
I used Gimp for a few years (basic work) before switching to PS and even after that I used Gimp from time to time. Work that I did in PS is mostly basic, so no problems here Wink


(02-16-2018, 05:28 PM)rich2005 Wrote: You are using Wacom tablet. Why did you need to force recognition? Can you expand on that? In linux even my ancient Wacom volito is supported. However, could be a problem with Windows.
The pressure dynamics didn't seem to work. I had to enable (set to "screen") Wacom Eraser and Stylus in "Configure Input Devices" and I also added "DirectX DirectInput" to "Additional Input Controllers" to be sure...


(02-16-2018, 05:28 PM)rich2005 Wrote: 24 Mp images, big but not that big, my lumix takes 18 Mp and Gimp handles those ok. (my laptop Kubuntu 16.04 is I5 6200U 8 GB memory) but always a but, are you short on disk space?
50GB free on the system drive...


(02-16-2018, 05:28 PM)rich2005 Wrote: Yes, do not use multiple processors in Gimp 2.9 use Edit -> Preferences -> System Resources set Number of threads to use to 1

I tried both single and multicore support. Doesn't seem to change brush lag, stability was ok with both settings.

(02-16-2018, 05:28 PM)rich2005 Wrote: That was fixed back in Gimp 2.8.16 or 2.8.18 - what version of Gimp are you using?

2.8.14 and 2.9.8. Thanks for pointing that - I will upgrade 2.8 ASAP.

(02-16-2018, 05:39 PM)Espermaschine Wrote: Probably not: but have you got the 'Smooth Stroke' option active, perhaps ?

I don't, when I tried it was even slower. Probably it's the brush size that causes the problem, but still, PS was faster. Maybe it's time to upgrade hardware, since 2.9 is even slower and I want it because of 16-bit support.


EDIT: it seems it's a bit better with 2.8.22. brushes up to 1000 - 1200 are quite usable.
Reply
#5
(02-16-2018, 05:58 PM)dr_Fell Wrote: Probably it's the brush size that causes the problem, but still, PS was faster.

Well what is the brush size ?
I had downloaded huge PS brushes in the past, which made Gimp laggy.

It seems in PS, bigger is better is true.
But this doesnt apply to Gimp. Especially because Brushes dont scale as well as in PS.
Reply
#6
(02-16-2018, 06:51 PM)Espermaschine Wrote:
(02-16-2018, 05:58 PM)dr_Fell Wrote: Probably it's the brush size that causes the problem, but still, PS was faster.

Well what is the brush size ?
I had downloaded huge PS brushes in the past, which made Gimp laggy.

It seems in PS, bigger is better is true.
But this doesnt apply to Gimp. Especially because Brushes dont scale as well as in PS.

Haha, that would do it. 

If you're doing more intense stuff, you may want to move back to PS?
Reply
#7
(02-16-2018, 07:39 PM)SeabassG33 Wrote: Haha, that would do it. 

If you're doing more intense stuff, you may want to move back to PS?

It was never a problem for me. Like i couldnt do something with a brush, because i couldnt make it big enough.
It just appears to me that some PS brushes are over the top when it comes to size.

Why would you paint on a pressure sensitive tablet with a, say, 1000x1000px brush ??
Reply
#8
Smile Thanks for all suggestions. Considering that Adobe Photography Plan cost is now almost 150 euro for one year and that for c.a. 400 euro I can buy an used laptop that is ~4x faster that my current one, I guess I wait a bit, gather some money and choose the second option. That will not only give me boost in Gimp (I hope big brushes 2.9 / 3.x with 16 bit will be usable and comfortable then), but also give nice boost to rest of the software that I use.

Espermaschine - I also abandoned Lightroom when I abandoned PS. Second RAW converter that I own doesn't support local adjustments, so my current RAW conversion workflow is, that I am creating two or more bitmaps from the raw, with different exposure correction and sometimes other different settings (like white balance) too, load them all as the layers, add mask to the layers and unmask the parts of every layer that I need (for example to highlight some parts of the scene and send others into the background,retain detail in the parts of the image that were close to overexposed, etc.). I need those large brushes to paint layer masks - bigger brush gives much more uniform and nice looking effects when I want to dim larger parts of the image, corners, etc. Smaller brush leaves visible and ununiform patterns, especially on even surfaces.

As for now it seems that I can accept the average lag that I am getting with 2.8.22, but brush lag on 2.9.x (especially when in 16-bit mode) is way too big. Any chance that next Gimp versions (and stable 3.x) will have better performance?
Reply
#9
Plenty of powerful open-source RAW converters around. Many/most of them are discussed on pxls.us.
Reply
#10
A quick test, my 10 year old Lenovo X61 - 1.8 MHz 2 core CPU - 2 GB memory. The only concession to modernity is a 128 GB SSD.

Xubuntu 16.04 - Gimp 2.9.9 (appimage) With a 4600x3600 pix image & large brush >1000 pix, it is very slow, more so on a layer mask.

CPU is not particularly stressed, memory not maxed out, swap partition is not being used, just slow to render/refresh the display.

Same image ( and 16 bit), same Gimp 2.9.9 in my Kubuntu 16.04 laptop 2.6Mhz 8GB memory and while there is still a lag, it is usable. More click and click again than a smooth action.

Looks like the solution is more resources.
Reply


Forum Jump: