View Issue Details

IDProjectCategoryView StatusLast Update
0013827ScribusGraphics / Image Framespublic2016-04-18 04:14
Reporterjeff Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionduplicate 
PlatformOffshore Oil RigOSFedora LinuxOS Version23
Product Version1.5.2.svn 
Summary0013827: In-frame image moving / panning is slow
DescriptionThe new and delicious feature where you can double-click an image frame and click+drag the image around within the frame is very cool, but it is slow, especially with photos over 5 megapixels or so. Scribus tries to show/animate every movement for every pixel travelled by the mouse, without taking shortcuts, as you can see there: http://jeff.ecchi.ca/public/scribus-1.5-image-panning.webm

I suppose you might change it to just move "invisibly" from point A to point B in one step, like dragging global image frames is done in Scribus in general, though in an ideal world it would be nice if we could "just" find a way to make this fast (same for global image frame movements) instead of losing the real-time visual feedback.
TagsNo tags attached.
PatchNo

Relationships

duplicate of 0013363 closed Repaint backlog / lag when resizing text frames 

Activities

jghali

2016-03-19 20:35

administrator   ~0039281

Last edited: 2016-03-19 20:49

I can only reproduce this on Linux virtual machines with very low graphics performance. Unable to reproduce this on a 5y old Windows 7 64bit laptop.

jeff

2016-03-19 21:58

reporter   ~0039285

That's interesting. I'm seeing this on a Radeon HD 7770 with the open-source radeon (radeonsi) drivers on X.org with GNOME Shell. My laptop with Intel graphics (everything else in the stack being the same) is 100% smooth, so it seems like this would happen only with some drivers.

Vladimir Savic

2016-03-20 13:52

reporter   ~0039287

I'm seeing this sporadically all over the place. For example, turning off rulers while selecting text in a text frame makes experience ultra-smooth. With rulers on, it is crawling. Panning, resizing... all affected.

It happens here on nvidia hardware with proprietary drivers. If I remember correct I have experienced that for the first time somewhere around qt5.3 or qt5.4 release. Could be some kind of change in their interaction with X11. Did that code change? AppImage runs equally slow, but running Scribus through wine makes performance noticeably better (!?).

Vladimir Savic

2016-03-21 23:47

reporter   ~0039320

With qt5.6 out and xorg-server 1.18.2 upgrade the issue is finally gone, and Scribus is fast as never before. Very modest comp specifications here: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+, 3GB RAM, nvidia 8500GT with proprietary drivers. 20MPix image panning is flying. And all that happens while compiling scribus from svn with "make -j2". Almost unbelievable. :D

Kunda

2016-03-22 03:24

updater   ~0039321

Last edited: 2016-03-22 12:50

Thanks vlada :)
jeff, please retest with Qt5.6 and report, Thanks!

htgoebel

2016-03-26 17:53

reporter   ~0039446

I can confirm this issue vanishes as soon as the rulers are turned of.

Tested on two machines:

* Machine A:
  scribus 1.5.0 and 1.5.1. Scribus 1.4.4 worked fine
  Qt 5.4.2, x11-server-xorg-1.16.4
  VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210]
  x11-driver-video-nouveau-1.0.11

* Machine B:
  scribus 1.5.0
  Qt 5.4.2, x11-server-xorg-1.16.4
  Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller
  x11-driver-video-intel-2.99.917

htgoebel

2016-03-26 18:04

reporter   ~0039447

Addendum: When moving the image within the frame, the *mouse* position is updated in the ruler and is lagging behind exactly as the image does.

So maybe simply *not* updating the position within the ruler solves the problem. IMHO there is no use in showing the mouse position in the rule while dragging the image since one can click the image *everywhere*. So the position of the mouse (in the ruler) is worth nothing.

Kunda

2016-03-31 04:32

updater   ~0039601

jeff, please test as well

jeff

2016-04-01 00:03

reporter   ~0039663

For what it's worth, testing with the same versions as what I had previously (I can only use whatever is available in Fedora 23 + luya's repository), with my test JPEG images at ~5000x3400 pixels, I see the issue even with the rulers turned off: there is a somewhat perceptible (25-50%?) performance improvement when rulers are turned off, but the dragging is still lagging a lot behind the mouse and follows its full trajectory in a snake-like fashion.

Kunda

2016-04-07 20:57

updater   ~0039893

luya, can you reproduce ?

luya

2016-04-11 17:20

reporter   ~0040076

Testing machine spec:

scribus 1.5.2 svn21141
VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R6 Graphics]
xorg-x11-drv-ati 7.6.1
xorg-x11-server-Xorg 1.18.3
Qt 5.5.1

I am able to reproduce the bug in question with the current build.
When moving from point A to B, the motion is sightly delayed. However, trying moving from A to C via B definitely slowdown the transition.
Here is the screencast: https://luya.fedorapeople.org/videos/Screencast%20from%2004-11-15%2010:23:28%20PM.webm

 I recently finished compiled svn21187 and will post a result shortly.

Kunda

2016-04-11 17:35

updater   ~0040077

hey luya, please test with Qt5.6
Thanks!

PeterBenedek

2016-04-11 17:37

developer   ~0040078

Last edited: 2016-04-11 17:44

Qt 5.5.1 causing trouble (Tested: Linux Mint 17.3). I have a similar experience.
Qt 5.6 It solved the problem.

Video 1 (Qt5.5.1 and 5.4.2): https://www.dropbox.com/s/1bv5fx3mb2vljw4/example_2.avi?dl=0

Video 2 (Qt5.5.1): https://www.dropbox.com/s/dgkszedcdn5hfb9/example.avi?dl=0
jeff, can test Qt5.6?

luya

2016-04-12 00:15

reporter   ~0040099

After upgrade Qt to 5.6.0, the slowdown of moving or panning an image within a frame no longer occurs.

For jeff, Fedora 23 now has qt 5.6.0 in updates-testing repository which fixes the issue. On minor nitpick is the slight jerkiness of the motion or panning but it is responsively fast.

Kunda

2016-04-12 04:59

updater   ~0040100

Thanks everybody that was involved.
Hat-tip to luya for upgrading Fedora build to Qt5.6
Resolving as duplicate of 0013363

Kunda

2016-04-13 13:46

updater   ~0040119

Jeff, did you update Fedora 23 and test ?

jeff

2016-04-17 16:44

reporter   ~0040222

Hi, I tested with the upgraded packages now, and the issue is gone indeed. Lightning fast.

Kunda

2016-04-18 04:14

updater   ~0040238

Closing

Issue History

Date Modified Username Field Change
2016-03-19 17:59 jeff New Issue
2016-03-19 20:32 jghali Relationship added related to 0013363
2016-03-19 20:35 jghali Note Added: 0039281
2016-03-19 20:49 jghali Note Edited: 0039281
2016-03-19 21:58 jeff Note Added: 0039285
2016-03-20 13:52 Vladimir Savic Note Added: 0039287
2016-03-21 23:47 Vladimir Savic Note Added: 0039320
2016-03-22 03:24 Kunda Note Added: 0039321
2016-03-22 12:50 Kunda Note Edited: 0039321
2016-03-26 17:53 htgoebel Note Added: 0039446
2016-03-26 18:04 htgoebel Note Added: 0039447
2016-03-31 04:32 Kunda Note Added: 0039601
2016-04-01 00:03 jeff Note Added: 0039663
2016-04-07 20:57 Kunda Note Added: 0039893
2016-04-11 17:20 luya Note Added: 0040076
2016-04-11 17:35 Kunda Note Added: 0040077
2016-04-11 17:37 PeterBenedek Note Added: 0040078
2016-04-11 17:39 PeterBenedek Note Edited: 0040078
2016-04-11 17:39 PeterBenedek Note Edited: 0040078
2016-04-11 17:40 PeterBenedek Note Edited: 0040078
2016-04-11 17:44 PeterBenedek Note Edited: 0040078
2016-04-12 00:15 luya Note Added: 0040099
2016-04-12 04:57 Kunda Relationship replaced duplicate of 0013363
2016-04-12 04:57 Kunda Status new => resolved
2016-04-12 04:57 Kunda Resolution open => duplicate
2016-04-12 04:57 Kunda Assigned To => Kunda
2016-04-12 04:59 Kunda Note Added: 0040100
2016-04-12 04:59 Kunda Assigned To Kunda =>
2016-04-13 13:46 Kunda Note Added: 0040119
2016-04-17 16:44 jeff Note Added: 0040222
2016-04-18 04:14 Kunda Note Added: 0040238
2016-04-18 04:14 Kunda Status resolved => closed