https://bugs.kde.org/show_bug.cgi?id=378275
--- Comment #4 from Nate Graham <pointedst...@zoho.com> --- The class documentation says: "QPlainTextEdit is a thin class, implemented by using most of the technology that is behind QTextEdit and QTextDocument. Its performance benefits over QTextEdit stem mostly from using a different and simplified text layout called QPlainTextDocumentLayout on the text document (see QTextDocument::setDocumentLayout()). The plain text document layout does not support tables nor embedded frames, and replaces a pixel-exact height calculation with a line-by-line respectively paragraph-by-paragraph scrolling approach." http://doc.qt.io/qt-5.9/qplaintextedit.html This suggests two options: 1. Suggest to the Qt folks that they re-architect QPlainTextEdit to support optional pixel-by-pixel scrolling while retaining as many of the performance benefits of the status quo as possible. This seems unlikely, but I have submitted an upstream bug report anyway: https://bugreports.qt.io/browse/QTBUG-63241 2. Change Kate and Konsole to use the QTextEdit class (which supports smooth pixel-by-pixel scrolling) and live with whatever performance penalty this imposes. We would definitely need to test with huge documents and lousy hardware to see at what point the performance penalty becomes noticeable, and decide if we can live with that. This seems like what we should focus on in the short to medium term, and make sure we test thoroughly to make sure the performance hit is either negligible or acceptable. Another consideration: if we wait for the Qt bug to be resolved (if it ever is), then we will have to wait before we can turn pixel scrolling until the version of QT that supports it is released and widely available, which may be quite a long time (if ever). -- You are receiving this mail because: You are watching all bug changes.
