Summary: | rendering/URL highlight: Highlight stays behind during scroll | ||
---|---|---|---|
Product: | [Applications] konsole | Reporter: | Dave Gilbert <gilbertd+kde> |
Component: | general | Assignee: | Konsole Developer <konsole-devel> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | a.samirh78, rdieter |
Priority: | NOR | ||
Version: | 2.13 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | A hacky patch that seems to work |
Description
Dave Gilbert
2014-04-25 20:33:10 UTC
I cannot reproduce this using konsole-4.13.0 Sorry, didn't follow *all* the steps, the important part is step 5, you have to be scrolled up a bit to trigger it. I've added a bit of debug, but still finding my way around konsole's data structures; when I hit return I see calls to updateImage that then calls scrollImage and paintFilters. PaintFilters is then drawing the line at the wrong location, it's 'spot' it's getting seem to correspond to where it ends up drawing the line (i.e. the wrong place). I don't see any calls to processFilters or scrollScreenWindow when I hit return. Created attachment 86421 [details]
A hacky patch that seems to work
This patch seems to work, but it's just the result of a bit of hacking around without really understanding konsole's data structures.
Do the filters really need to be updated on every update? If not exactly which updates need to trigger it?
(I was going to make this only happen when the scroll amount was non-0 which is why I put the flag set where it is, but I think always doing it is fixing more cases).
The issue doesn't seem to happen any more with konsole5 and konsole4/kde4 is no longer maintained. |