View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013827 | Scribus | Graphics / Image Frames | public | 2016-03-19 17:59 | 2016-04-18 04:14 |
| Reporter | jeff | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | duplicate | ||
| Platform | Offshore Oil Rig | OS | Fedora Linux | OS Version | 23 |
| Product Version | 1.5.2.svn | ||||
| Summary | 0013827: In-frame image moving / panning is slow | ||||
| Description | The 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. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
| duplicate of | 0013363 | closed | Repaint backlog / lag when resizing text frames |
|
|
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. |
|
|
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. |
|
|
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 (!?). |
|
|
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 |
|
|
Thanks vlada :) jeff, please retest with Qt5.6 and report, Thanks! |
|
|
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 |
|
|
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. |
|
|
jeff, please test as well |
|
|
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. |
|
|
luya, can you reproduce ? |
|
|
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. |
|
|
hey luya, please test with Qt5.6 Thanks! |
|
|
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? |
|
|
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. |
|
|
Thanks everybody that was involved. Hat-tip to luya for upgrading Fedora build to Qt5.6 Resolving as duplicate of 0013363 |
|
|
Jeff, did you update Fedora 23 and test ? |
|
|
Hi, I tested with the upgraded packages now, and the issue is gone indeed. Lightning fast. |
|
|
Closing |
| 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 |
