After a long time of constant distraction by my daily work, I finally found again a bit time to take care of KTextEditor/Kate/… issues.
One thing that really started to be an itch I wanted to scratch is some rendering fault that occur with ‘special’ font sizes.
Given I wanted to do again a bit work on the macOS port, I was really annoyed that on my screen the only application with text rendering issues was “my” one :/
I assume a lot of people have sometimes seen stuff like that in KTextEditor based applications like Kate or KDevelop:
These small white lines really stick out like a sore thumb 🙁 It looked like some off-by-one rounding issue, surely one should be able to find it…
I tried to track down where in our rendering in KTextEditor we do create these artifacts, but I never found any place that looks like a possible cause.
After a bit more tinkering it became obvious that actually it would be more or less impossible for the KTextEditor code to mess up the painting in such a way, as we normally draw one line more or less as one thing using QTextLayout that handles the painting of the selection background, too.
Using QtCreator as an non-KTextEditor based application that uses the Qt layouting & rendering it was possible to get similar effects on macOS (or X11):
:=) Good thing that Qt is open source. A quick look into the qtextlayout.cpp and a qt5 compile later, I was able to trace the issue down to some qFloor calls for painting the selections.
At least for the syntaxhighlighter example shipped with Qt I was able to reproduce the issue before my patch but not afterwards.
Would Qt not be open-source, I would have been at the end of the line after seeing no “error” in our codebase in KTextEditor.
With Qt as some open-source project, it is a completely different story.
Besides, the Qt documentation for “how to build it” and “how to contribute” on the Qt Wiki are well enough to understand that I was able to nicely compile the stuff from scratch on macOS and provide the Gerrit review request in no time.