On 04/13/2018 05:42 PM, Brombur wrote:

I decided to give gimp another go. I've updated my video and run an ok pc with decent stats but when I use gimp and try to move any image, of any size or resolution the image lags when i position it. even on simple single color layers. If i make a red box and try to move it the image is so choppy it looks like Im watching a picture download circa 1995.

Any idea?

You should describe this in a way that gives others the chance to reproduce exactly what you got - assume that they know how to use GIMP, but do not know what commands you use.

By following your instructions, they should have the same image as you and be able to do the positioning just like you.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

On 04/13/2018 11:42 AM, Brombur wrote:

I decided to give gimp another go. I've updated my video and run an ok pc with decent stats but when I use gimp and try to move any image, of any size or resolution the image lags when i position it. even on simple single color layers. If i make a red box and try to move it the image is so choppy it looks like Im watching a picture download circa 1995.

Any idea? I don't have this problem when I run Pixlr and when I ran my demo of photoshop.

The only times I have seen the GIMP act like that (15+ years across /numerous/ machines and operating systmes) it was always a memory issue, typically due to working on a fairly huge image with many full size layers and LOTS of "undo" steps saved.

Fist check the size of the images you are working with, in pixels: This is shown in the canvas window title bar, after the name of the open file. If the X and Y dimensions are in the multiple thousands of pixels, that could be the problem.

I will guess that you are using GIMP 2.8, not a development build; if not, this may be incorrect (or not): Go to Edit > Preferences, and in the Environment menu (should be the one that opens by itself) and check the Tile Cache Size item. "When the amount of pixel data exceeds this limit, GIMP will start to swap tiles to disk." That sounds very much like what you are seeing when you move things around on the canvas. I normally like to set this limit to about half of total system RAM, more if the machine has a huge amount of memory, less if the system doesn't have memory to spare.

On my laptop which does not have a huge amount of memory, I start seeing a /small/ amount of lag when moving image-sized layers at about 2500 x 2500 pixels - noticeable, but does not slow my workflow down. At 4000 x 4000 pixels it gets more noticeable; I would have to adjust my maximum image size setting (same menu as above) to test at 4500 px or above...

Hopefully this will put you on the trail to a solution. If none of the above seems to apply, check all running processes on the machine to see if some background process is eating up a huge amount of system memory. poss8ible.

:o)

If you have the ability to record your steps on video then that could be more helpful than static screenshots and verbal explanations. But as a quick experiment, I can confirm that moving layers can result in slow redraw times, potentially creating general visual mess (but the move operation otherwise executes normally and the visual artifacts do clean themselves up afterwards).

If you had a case where the "lag" between moving a layer and the window updating got continually worse the more you kept moving the layer, that would be indicative of a cascading event. Fortunately, that doesn't seem to be the case here....

Some caveats I noticed:

- The size of the image canvas, layer in question, and current zoom level seem to have no impact on redraw times; only the actual size of the image window whose area is being redrawn.

- Visual artifacts are most noticeable when moving the object upwards.

- Using the Pan function (Spacebar) always results in smooth movement as it is not actually making changes to the image, just scrolling its position within the image window.

I do notice that during the move operation all visual redraws originate from the upper-left of the moved object. Not necessarily a bad choice, but could the redraw perhaps originate from the cursor's current location within the image window, redrawing outwards? After all, when you're clicking and dragging something, the area around the cursor is generally what your vision is focused on....

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

From: gimp-user-list  on behalf of Brombur 
Sent: Wednesday, April 18, 2018 6:13:05 PM
To: gimp-user-list@gnome.org
Cc: notifications@gimpusers.com
Subject: [Gimp-user] Image doesn't move smoothly

>I run a dell with 8 gigs of ram and a 3.4 ghz i5 processor. it plays
>online games no problem and again doesn't have any issue with drag on
>pixlr. I have been working on 3500x3500 images on pixlr and I kept
>that file size for gimp 2 and it has issues.

Just tested on a 2400x2400 image and had the same issue. All i had on the page
was a layer with a solid black box. I would move the layer and is was a mess.


--
Brombur (via www.gimpusers.com/forums)

On 04/20/2018 08:08 PM, Richard wrote:

If you have the ability to record your steps on video then that could be more helpful than static screenshots and verbal explanations. But as a quick experiment, I can confirm that moving layers can result in slow redraw times, potentially creating general visual mess (but the move operation otherwise executes normally and the visual artifacts do clean themselves up afterwards).

If you had a case where the "lag" between moving a layer and the window updating got continually worse the more you kept moving the layer, that would be indicative of a cascading event. Fortunately, that doesn't seem to be the case here....

Some caveats I noticed:

- The size of the image canvas, layer in question, and current zoom level seem to have no impact on redraw times; only the actual size of the image window whose area is being redrawn.

- Visual artifacts are most noticeable when moving the object upwards.

- Using the Pan function (Spacebar) always results in smooth movement as it is not actually making changes to the image, just scrolling its position within the image window.

I do notice that during the move operation all visual redraws originate from the upper-left of the moved object. Not necessarily a bad choice, but could the redraw perhaps originate from the cursor's current location within the image window, redrawing outwards? After all, when you're clicking and dragging something, the area around the cursor is generally what your vision is focused on....

Now this starts to sound like an actual bug in the program. What version of the GIMP, on what operating system & operating system version, is doing this? Is there a difference when the image is set to RGB, indexed or grayscale?

The problem Brombur describes and Richard at least partially confirms may be a 'known issue' or it may need a bug report filed.

On Sat, Apr 21, 2018 at 8:52 PM, Steve Kinney wrote:

Some caveats I noticed:

- The size of the image canvas, layer in question, and current zoom level seem to have no impact on redraw times; only the actual size of the image window whose area is being redrawn.

- Visual artifacts are most noticeable when moving the object upwards.

- Using the Pan function (Spacebar) always results in smooth movement as it is not actually making changes to the image, just scrolling its position within the image window.

I do notice that during the move operation all visual redraws originate from the upper-left of the moved object. Not necessarily a bad choice, but could the redraw perhaps originate from the cursor's current location within the image window, redrawing outwards? After all, when you're clicking and dragging something, the area around the cursor is generally what your vision is focused on....

Updating the display as quick as possible after receiving motion events, rather than rendering everything and updating at a low frame-rate, is a known feature - not a bug. Until things are fast enough to do 15fps of the entire viewport - for instance with GIMP integrating with and using the mipmap based preview-rendering infrastructure in GEGL, always waiting until we have a full "frame" to present will significantly increase latency leading to a worse user experience than presenting as much rendered content as soon as possible.

/pippin

On 04/21/2018 03:16 PM, Øyvind Kolås wrote:

Updating the display as quick as possible after receiving motion events, rather than rendering everything and updating at a low frame-rate, is a known feature - not a bug. Until things are fast enough to do 15fps of the entire viewport - for instance with GIMP integrating with and using the mipmap based preview-rendering infrastructure in GEGL, always waiting until we have a full "frame" to present will significantly increase latency leading to a worse user experience than presenting as much rendered content as soon as possible.

/pippin

So there's eyeballs on this and nothing's broken, just a tad bit slow in some instances due to the overhead of accurate rendering of very large data sets remapped from Here to There. I can live with that. Have for many years without seeing it as a problem. :D