Created attachment 166655 [details] after comparison I think it started with the previous version, 1.10.3, after which I upgraded to 1.10.4, but the issue persists. The display is not displaying, refreshing or (re)painting properly, and I don't think any other kde program (or any other non-kde program either) has the same issue, so I don't think it is library related. STEPS TO REPRODUCE 1. Launch kdiff3 2. 3. OBSERVED RESULT Large areas of the display are missing. Icons, menus, text, all are cut off. Best to see photos to see what I mean. I can run a comparison from the command line, and it goes through, so the program is not hung or frozen. Hovering or scrolling can trigger repaints but the results are still garbled. I have found no other reports online of anything like this, even in forums. EXPECTED RESULT SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Core 37 qt-4.8.7-69.fc37.x86_64 kf5-plasma-5.105.0-1.fc37.x86_64 (I'm running in mate desktop, in case that makes a difference = mate-common-1.26.0-3.fc37.noarch) ADDITIONAL INFORMATION
Created attachment 166656 [details] configure menu
Created attachment 166657 [details] file menu
Created attachment 166658 [details] file menu after moving cursor left
Created attachment 166659 [details] file menu submenu after moving cursor up and down
Actually, just ran into this: https://bugs.archlinux.org/task/78488 which says the problem started at 1.10.2-1 with one person claiming it was resolved in 1.10.3-1
If you are using qt older then 5.12.0 then KDiff3 does not even support building against such a version. Neither does kf5. Could you double check the qt version on your system there maybe more the one version installed.
(In reply to michael from comment #6) > If you are using qt older then 5.12.0 then KDiff3 does not even support > building against such a version. Neither does kf5. Could you double check > the qt version on your system there maybe more the one version installed. Oops, sorry about that, I forgot that the package name is qt5 (not qt). Here's the current qt5 version on this system: qt5-qtbase-5.15.9-3.fc37.x86_64
I found another application with the same issue: > $ sqlitebrowser --version > DB Browser for SQLite Version 3.12.99 (Feb 28 2022) > > Built for x86_64-little_endian-lp64, running on x86_64 > Qt Version 5.15.2 > SQLCipher Version 4.4.3 community (based on SQLite 3.34.1). > $ rpm -q sqlitebrowser > sqlitebrowser-3.13.0-0.3.gita302128.fc35.x86_64 I upgrade that to: > $ sqlitebrowser --version > DB Browser for SQLite Version 3.12.99 (Jul 23 2022) > > Built for x86_64-little_endian-lp64, running on x86_64 > Qt Version 5.15.5 > SQLCipher Version 4.4.3 community (based on SQLite 3.34.1). > $ rpm -q sqlitebrowser > sqlitebrowser-3.13.0-0.4.gita302128.fc37.x86_64 And same problem. Both versions have the same issue as the one described for kdiff3 in this bug report. I will investigate further to see if I can find any clues
Lots of these repeated when running sqlitebrowser: > QPainter::setPen: Painter not active > QPainter::setBrush: Painter not active > QPainter::drawRects: Painter not active But kdiff3 doesn't have any errors on stderr or stdout
As there seems to be something wiered going on with your setup. I am closing this for now. Looks like frame works /qt is having issues drawing.
I was actually experimenting with this since yesterday, trying git versions from the last few years, including 2018 and 2016.. running kdiff3 in a xephyr window in plasmashell, etc.. still happens in all of those cases, so I think it must be a missing dependency of some sort. Something both kdiff3 and sqlitebrowser need, that no other kde app that I use need. Or something they both use (some config file? gtk2/3 related?) that no other kde app I use has issues with. I tried doing an `ldd` on it as well, but still no clue at all what could be causing the issues. So kdiff3 is unusable to me as it is. Which is a real shame because I really like it and prefer it to kompare. If anyone can point me in any useful direction on this I would greatly appreciate it.
If it helps, what seems to be happening is that widgets (or fonts?) seem to be scaling away from the top left corner. Like they are being sheared, and then not fitting correctly where they are supposed to be drawn. So, the top-left-most file menu seems to be mostly in line, but then the "Help" menu entry is maybe some 40-50 pixels to the right of where its respective context menu appears below it. I tried changing the font size of everything but nothing. The issue affects even the "settings" config window, the "about" window, etc.
I just ran into this by @cullman (from 6 years ago) and it sounds a *lot* like this bug: https://cullmann.io/posts/kde-qt-highdpi-scaling/ I am on dual monitor setup (1920x1080 each), but not high dpi (96dpi). Christoph also links to: https://bugreports.qt.io/browse/QTBUG-78964 https://bugreports.qt.io/browse/QTBUG-78962 https://bugreports.qt.io/browse/QTBUG-78963 https://forum.qt.io/topic/129470/qt-widgets-application-scaling-on-different-resolution-screens/5 I'll see if any of these can yield some solution for me.
Well, as luck would have it, I just found this: https://discuss.kde.org/t/per-window-scaling/13620 and running kdiff3 like this: > QT_SCALE_FACTOR=1.5 kdiff3 makes everything huge, but no more artifacts. Scales of "0.5" and "1" do not work (0.5 makes it MUCH worse). Anything from 1.1 and up, all "work". Tried the same with `sqlitebrowser`: > QT_SCALE_FACTOR=1.1 sqlitebrowser And not only does it fix the artifact problem, but also, very interestingly, all the dozens of > QPainter::drawRects: Painter not active > QPainter::setPen: Painter not active messages that used to appear on the console no longer appear at all. The minimum QT_SCALE_FACTOR value to prevent the bug(s) seems to be 1.07 In any case, I have my workaround. Not sure if this means this is now a Qt bug or what, but maybe @cullman can use this information for good. :) More references: https://github.com/qutebrowser/qutebrowser/issues/5211 https://bugs.kde.org/show_bug.cgi?id=390451 (see especially: https://bugs.kde.org/show_bug.cgi?id=390451#c12 ) https://bugreports.qt.io/browse/QTBUG-66036#comment-479182 Given 390451 (and https://bugreports.qt.io/browse/QTBUG-66036#comment-479441 -- which suggests using QRectF instead of QRect to solve the bug mentioned there), can we re-open this?
Qt 5 does not have full support for high resolution monitors and for this reason the hi-res flags are off by default when creating a QGuiApplication. Qt6 is the current support version as of kdiff3 1.12.x this is also a required minimum. Especially if kdiff3 is not the only program affected I would say this is likely Qt related. Does 1.12.2 resolve the issue. A flatpak version is available as I realize not all distro's will have Qt 6.6 as is required for text codec support. QRectF is sometime I can look at for the current branch and master if it will improve the situation.
Moving to needs info to verify if 1.12.x / Qt6 is impacted. Qt5 is no longer supported in current release code. Master and 1.12 are current maintained versions. Its good to hear about the workaround as inconvenient as that is.
@michael, thanks! As I was typing up some more info to include yesterday my browser crashed, and then I found some more useful info today. So it seems that running kdiff3 with the QT_FONT_DPI env var set to 96 (since the dpi on my machine is 96) fixes it for me as well: > QT_FONT_DPI=96 kdiff3 The variable is somewhere being set to "90", but despite running a grep on what might be my entire filesystem, I cannot find where this variable is being set. The lights went out for a moment today and I had a chance to do a couple of experiments, running a barebones X server with xterm shows that these variables are not set by any of the bash sourced files. Even after launching my panel (mate-panel) from xterm the variables are not set. Konsole is not setting them either and when I run kdiff3 in that environment, the bug does not appear. So something in between sddm (my display manager) and mate-session is loading up these variables --and something else-- and triggering this bug. I say "something else" because unsetting both QT_SCALE_FACTOR and QT_FONT_DPI does not fix it. One or the other has to be set to the values I mentioned for the fix to happen. I really don't know how else to diagnose where the problem is being introduced, but it certainly only affects these two apps on my machine. No amount of searching has let me to find where mate (or sddm?) could be setting these environment variables.
Just to chime in why I kinda woke the wolves here yesterday: - Basically I'm using Lubuntu 24.10. - I was using LXDE with a 1920x1200 layout until last week. kdiff3 ran without problems. - Last week I switched to XFCE (LXDE being essentially dead by now). I also got a new monitor with 3840x2160 layout, and kdiff3 acted weird. While kdiff3 in LXDE is still running normally even with that resolution, it's broken in XFCE: - image scrollbars are completely black or showing kinda "noise" - toolbar icons are cut off - menu frames are cut off - clicking to select a section doesn't work most of the time But: Using Raphael's DPI settings from comment #17 above, it's working (and looking) well again! :)
Ok, I fixed it. In main.cpp:86, I just commented out the following: > //QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough); recompiled. Everything looks great. I'm still trying to fix my access to invent.kde.org, but I can submit this as a patch, unless you guys want a more robust fix. But this seems to work perfectly for me.
Just found this: https://github.com/sqlitebrowser/sqlitebrowser/issues/3811 I let them know about this bug report too. Interestingly, their findings are that the bug arises in combination of mate desktop and nvidia (which is my setup as well). And they found that the env vars are being set by mate through a setting that can be changed in dconf (via `dconf-editor`): > / org / mate / desktop / font-rendering / dpi set the value there for what will become the value of QT_FONT_DPI after restarting the session (I have not confirmed this yet, but it was indeed set to 90 for me, which I now changed to 96). So there's a better workaround/solution then, while we wait for the code fix (hopefully?)
Created attachment 179984 [details] attachment-3519608-0.html
This issue may may be examined if still present on kdiff3 master/ current 1.12.x branch with Qt6. setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough) is currently a noop as qt6 defaults to this setting. According to the docs odd issues may still appear due to floating point math in general being prone to rounding errors. So far no such report has been received for the current Qt6-only branches of kdiff3.