Summary: | Okular has an extemely high latency when scrolling with a wacom tablet | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | Keziolio <keziolio123> |
Component: | general | Assignee: | Okular developers <okular-devel> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | aacid, nate |
Priority: | NOR | ||
Version: | 1.5.1 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/okular/5ef54e97ecd2e2a7557de9cb5e07c55a172b55e1 | Version Fixed In: | 19.04.0 |
Attachments: | path |
Description
Keziolio
2018-09-29 11:22:58 UTC
Not major Which update exactly broke it? You could git-bisect Okular changes, but since you mention 'xorg' process has 100%, it probably is a video driver issue. I compiled okular 1.1.3 and 1.0.3 and the problem was still present, I'm pretty sure that the regression was more recent than that... So where should I look? I haven't noticed this kind of slowdown in other parts of the system, there's something that breaks okular in a specific way... I think the problem can be worked around by consuming the input as fast as possible and updating the page position once every screen refresh, I can mind a bad framerate but not 30+ seconds of latency, I think this is still an okular issue, but I was not even able to find the relevant file/function in the okular source code and it's not that well documented, if someone can help in that regard that'll be great This is the output of perf top when the latency is rolling: Samples: 347K of event 'cycles:ppp', 4000 Hz, Event count (approx.): 74074580252 Overhead Shared Object Symbol 34.75% [kernel] [k] copy_user_enhanced_fast_string 3.13% [kernel] [k] __check_object_size 1.64% libc-2.28.so [.] __memmove_avx_unaligned_erms 1.38% [kernel] [k] __radix_tree_lookup 1.03% perf [.] hpp__sort_overhead I tried with the nvidia card in my hybrid graphics laptop, running okular with bumblebee, the problem is reproduced (it can still be an intel bug, idk) I tried in my tablet with a touchscreen (and intel soc), and the problem is reproduced, so it's not only the wacom tablet that causes the bug, but probably everything that works like a touchscreen Why did you assign the bug to yourself? If you do that the rest of the world stops getting emails, so don't do that. sorry :C I made a patch that fixes the issue, can you look into it? Created attachment 115966 [details]
path
Please use Phabricator for patches https://community.kde.org/Get_Involved/development#Submitting_your_first_patch It seems that it's Qt's job to avoid this issue, or, at least, there's a difference in how Qt handles the mouse vs the touch thing I opened a Qt bug report for this issue: https://bugreports.qt.io/browse/QTBUG-71708 So I'm closing this for now Git commit 5ef54e97ecd2e2a7557de9cb5e07c55a172b55e1 by Nate Graham, on behalf of Kezi Olio. Committed on 05/04/2019 at 16:34. Pushed by ngraham into branch 'Applications/19.04'. Set Qt::AA_CompressTabletEvents attribute to avoid latency when scrolling with a tablet Summary: See also: https://bugreports.qt.io/browse/QTBUG-71708 Enabling this option _vastly_ improves the user experience on wacom tablets and touchscreens Reviewers: #okular Subscribers: sander, aacid, okular-devel, #okular Tags: #okular Differential Revision: https://phabricator.kde.org/D16519 M +1 -0 shell/main.cpp https://commits.kde.org/okular/5ef54e97ecd2e2a7557de9cb5e07c55a172b55e1 |