On Tue, Aug 10, 2010 at 11:17 AM, Dave wrote:

I experienced lag on brush strokes with CPU utilization maxing out at 100% (it was always high even with 2.6) but is bad enough that I've reverted back to 2.6.10. Single or multi window interface didn't make much difference so I suspect the new brush engine?

There are two aspects to this, namely wether transforms are on or not, but in general basic brush performance with transforming turned off is actually expected to be better than 2.6 series , because there is at least the outline drawing optimization in place.

Can you please describe your setup in more detail?

On Tue, Aug 10, 2010 at 11:17 AM, Dave wrote:

I experienced lag on brush strokes with CPU utilization maxing out at 100% (it was always high even with 2.6) but is bad enough that I've reverted back to 2.6.10. Single or multi window interface didn't make much difference so I suspect the new brush engine?

There are two aspects to this, namely wether transforms are on or not, but in general basic brush performance with transforming turned off is actually expected to be better than 2.6 series , because there is at least the outline drawing optimization in place.

Can you please describe your setup in more detail?

-- --Alexia

P.S Please register to the list. Using this forum front-end is... Well, I feel its somewhat rude.

On Tue, 2010-08-10 at 10:17 +0200, Dave wrote:

I experienced lag on brush strokes with CPU utilization maxing out at 100%

Do you have compositing on? (e.g. do windows have a drop shadow round them?)

Turning that off helps a lot on my laptop.

Liam

On 8/10/10, Dave wrote:

I've reinstalled 2.7.2 (not 2.7.3 as in the title). I don't like the tapering effect of the 'Basic Dynamics' brush setting so I've created my own that sets opacity only so as to emulate what I would typically use in 2.6. However irrespective of the brush dynamic the brush lags during use. The lag is unnoticeable with a small 1600x1200 single layer file, but very noticeable on one that is 1521X2807 with 10 layers. I typically work on files double that size in 2.6 without issue.

And typical brush size would be...?

Alexandre Prokoudine http://libregraphicsworld.org

On Tuesday, August 10, 2010, 21:47:08, Dave wrote:

I only use the brush tool, mostly with hard round brushes any size typically up to about 25 pixel radius, spacing 10. opacity on. no other brush dynamics set. Smaller the brush the better the performance is.

Can you please fix your e-mail client so that it: - doesn't remove the References and In-Reply-To headers to enable proper threading of your messages
- quotes the message you're replying to - doesn't send HTML when it's completely unnecessary

(also, where did you find GIMP 2.7.3? The latest 2.7 release is 2.7.1)

probably he compile the a devel version - my previous compilation reported itself as 2.7.3 but the newest is 2.7.2 ;)

2010/8/11 Jernej Simon?i? :

On Tuesday, August 10, 2010, 21:47:08, Dave wrote:

I only use the brush tool, mostly with hard round brushes any size typically up to about 25 pixel radius, spacing 10. opacity on. no other brush dynamics set. Smaller the brush the better the performance is.

Can you please fix your e-mail client so that it: - doesn't remove the References and In-Reply-To headers to enable  proper threading of your messages
- quotes the message you're replying to - doesn't send HTML when it's completely unnecessary

(also, where did you find GIMP 2.7.3? The latest 2.7 release is 2.7.1)

-- < Jernej Simon?i? ><><><><>< http://eternallybored.org/ >

Problems worthy of attack prove their worth by hitting back.       -- Hein's Law

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tuesday, August 10, 2010 22:47:08 Dave wrote:

I only use the brush tool, mostly with hard round brushes any size typically up to about 25 pixel radius, spacing 10. opacity on. no other brush dynamics set. Smaller the brush the better the performance is.

Do you use a tablet?

There are really no changes in GIMP that should degrade performance for larger brushes. There is a little more interpolation, but that should affect all brush sizes either equally or larger brushes less.

Also, what GTK is the build you have using?

Im sorry, If I seemed unfriendly. I just find putting a mailing list behind a forum front end with posting option to be of poor taste... Not really your fault.

On Tuesday, August 10, 2010 23:27:15 Jernej Simon?i? wrote:

Can you please fix your e-mail client so that it: - doesn't remove the References and In-Reply-To headers to enable proper threading of your messages
- quotes the message you're replying to - doesn't send HTML when it's completely unnecessary

He cant. He was using the "forum" client gimpusers has. He probably does not have any mail to reply too...

(also, where did you find GIMP 2.7.3? The latest 2.7 release is 2.7.1)

theres an ubuntu PPA with shifted versioning. It should be GIT nightly build AFAIK.

Hi,
jernej@ena.si (2010-08-10 at 2227.15 +0200):

(also, where did you find GIMP 2.7.3? The latest 2.7 release is 2.7.1)

Unofficial "releases" claiming "random" numbers. Some even claim things like:

"... An update: actually, the version of the currently installed unstable GIMP is 2.7.3-2010022601, even if it says 2.7.1 in the Info window."

GSR

On Tuesday, August 10, 2010, 22:48:33, Alexia Death wrote:

He cant. He was using the "forum" client gimpusers has. He probably does not have any mail to reply too...

In that case gimpusers should fix their forum client. I'm not that bothered by the HTML, but having neither threads, nor quotes makes getting a message context practically impossible.

On Wednesday, August 11, 2010 01:27:48 Dave wrote:

Wow, guys, If you want to use the mailing list that's fine. but lets remove the forum front end or make it read only so that we have a standard. Don't beat me up over it.

We dont have control over what gimpusers have on their site as its a 3rd party site. Sorry again, if I have been beating you up over it.

I used the ubuntu ppa found here:

https://launchpad.net/~matthaeus123/+archive/mrw-gimp-svn

The version keeps changing. Previous time I tried it, it quoted 2.7.3, now it says 2.7.2

Ah, corrected the error then.

Yes I use a wacom intuos3 with pressure sensitivity switched on in gimp.

I have the same setup then.

I'm aware I havent given you anything other than my unscientific empirical experience here and I would be amazed if anyone could diagnose anything from that. It could be the PPA build is dodgy. It could be my config. Who knows. I was hoping someone would just jump up and say yes we know its work in progress.

Your problem is interesting, because its contrary to what I would expect and experience myself. For me GIT version performs about twice as good as 2.6, especially with large brushes, and thats with compositing on. To get the 25px round brush to lag at all I have to move lightningfast. and then it usually catches up in under 2 seconds. My hardware configuration is admittedly slightly better than yours... But 25px brushes really shouldnt be a problem anywhere.

Maybe there should be a call for more peoples experiences to try and build a bigger picture....

Yes. perhaps. but experiences dont help me fix the problem if there is one. Someone who can build gimp themselves and use a profiler and has this issue would really help.

-- Alexia

In view of what Alexia just said:

Your problem is interesting, because its contrary to what I >would expect and experience myself. For me GIT version performs about twice >as good as 2.6, especially with large brushes, and thats with compositing on. >To get the 25px round brush to lag at all I have to move lightningfast. and >then it usually catches up in under 2 seconds. My hardware configuration is >admittedly slightly better than yours... But 25px brushes really shouldnt be a >problem anywhere.

I am suspecting your Xorg server version, config, or video hardware has changed as well as your GIMP version. I found myself, that redraws in paint programs were intolerably slow until I added the

Option "AccelMethod" "XAA"

to the video card config in my xorg.conf. (EXA is the default, and makes 3d performance much better, but unfortunately seems to cripple 2d painting performance on my card. XAA might effect compositing (as in WM compositing) speed significantly instead.)

Perhaps you could try the above option and see if it makes any difference.

FYI, I have an ATI Radeon 9800 or thereabouts. I've read that this problem does not occur on NVidia cards and newer ATI cards.

[incidentally, 2.7 uses Cairo more for display related things (not for rendering brushes IIRC, but of course in order to see the rendered brush strokes, the area must be displayed). It's possible that this impacts your system significantly while using the default EXA acceleration. So it could be a combination of a change in GIMP and annoying hardware/driver misconfiguration.]

HTH,

another Dave :)

On Wednesday, August 11, 2010 02:58:56 David Gowers wrote:

[incidentally, 2.7 uses Cairo more for display related things (not for rendering brushes IIRC, but of course in order to see the rendered brush strokes, the area must be displayed). It's possible that this impacts your system significantly while using the default EXA acceleration. So it could be a combination of a change in GIMP and annoying hardware/driver misconfiguration.]

There is a change there that puts a little more pressure on the graphics card to keep up, the event fill. It should not be an issue for properly functioning graphics hardware, the optimizations elsewhere make up the tiny slowdown it introduced with large surplus, but in combination with GPU not taking its share of the display update load, it can can theoretically perform worse than 2.6.

And now Im remembering that years ago I had a 9800SE radeon card and I actually needed to change that option too to have any performance in painting apps.

Hi,
00ai99@gmail.com (2010-08-11 at 0928.56 +0930):

I found myself, that redraws in paint programs were intolerably slow until I added the

Here it was general. GIMP's interface took a couple of seconds to redraw, but so did FF while scrolling (slideshowing would describe it better).

Option "AccelMethod" "XAA"

to the video card config in my xorg.conf. (EXA is the default, and makes 3d performance much better, but unfortunately seems to cripple 2d painting performance on my card. XAA might effect compositing (as in WM compositing) speed significantly instead.)

Perhaps you could try the above option and see if it makes any difference.

FYI, I have an ATI Radeon 9800 or thereabouts. I've read that this problem does not occur on NVidia cards and newer ATI cards.

Other thing to try is keeping EXA but with: Option "MigrationHeuristic" "greedy"

GSR

On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR wrote:

Hi,
00ai99@gmail.com (2010-08-11 at 0928.56 +0930):

I found myself, that redraws in paint programs were intolerably slow until I added the

Here it was general. GIMP's interface took a couple of seconds to redraw, but so did FF while scrolling (slideshowing would describe it better).

        Option      "AccelMethod" "XAA"

to the video card config in my xorg.conf. (EXA is the default, and makes 3d performance much better, but unfortunately seems to cripple 2d painting performance on my card. XAA might effect compositing (as in WM compositing) speed significantly instead.)

Perhaps you could try the above option and see if it makes any difference.

FYI, I have an ATI Radeon 9800 or thereabouts. I've read that this problem does not occur on NVidia cards and newer ATI cards.

Other thing to try is keeping EXA but with: Option          "MigrationHeuristic" "greedy"

I've just tried this and it works for me. MyPaint becomes is just as responsive as with XAA, except for the panning. GIMP is a jerk (I get cases where I draw a curve and the middle of it gets flattened into a straight line); But I haven't been painting anything with GIMP recently so I don't know whether it's also a jerk with XAA. 3d performance in Blender is fairly poor (but noticably better than with XAA)

Panning in both MyPaint and GIMP (and Firefox) is still noticably slower. Fast smooth panning is important to me, so I will switch back to XAA.

On Wed, Aug 11, 2010 at 12:12 PM, David Gowers wrote:

On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR wrote: GIMP is a jerk (I get
cases where I draw a curve and the middle of it gets flattened into a straight line); But I haven't been painting anything with GIMP recently so I don't know whether it's also a jerk with XAA.

It is. Looks like I have a bug to file.

On Wednesday, August 11, 2010 06:04:36 David Gowers wrote:

On Wed, Aug 11, 2010 at 12:12 PM, David Gowers wrote:

On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR wrote: GIMP is a jerk (I get
cases where I draw a curve and the middle of it gets flattened into a straight line); But I haven't been painting anything with GIMP recently so I don't know whether it's also a jerk with XAA.

It is. Looks like I have a bug to file.

Not with GIMP. Its a bug in the wacom driver. Top end of the pressure scale ends up with pressure 0. And I have a vague memory thats fixed somewhere in development pipeline.

-- Alexia.

On Thu, Aug 12, 2010 at 7:24 AM, Alexia Death wrote:

On Wednesday, August 11, 2010 06:04:36 David Gowers wrote:

On Wed, Aug 11, 2010 at 12:12 PM, David Gowers wrote:

On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR wrote: GIMP is a jerk (I get
cases where I draw a curve and the middle of it gets flattened into a straight line); But I haven't been painting anything with GIMP recently so I don't know whether it's also a jerk with XAA.

It is. Looks like I have a bug to file.

Not with GIMP. Its a bug in the wacom driver. Top end of the pressure scale ends up with pressure 0. And I have a vague memory thats fixed somewhere in development pipeline.

I have the fixed version already.(0.10.8)

Believe me, after experiencing THAT problem, I would know about it. Generally that problem resulted in the stroke ending and no more drawing until I eased off on the pressure.

This is a different bug (and, MyPaint also uses the GTK+ input code and does NOT experience this bug at all no matter how fast I move)