Closed th closed 2 years ago
We have code in there that is supposed to enable high dpi support.. but wxWidgets is an old API that may not deal with it well in places. Not sure to what extend we can fix it.
That's fair, thank you!
push, I use also treesheets on HiDPI Display (Gnome, Debian) plz add some support of this display.
THANXX :-)
Is there a way to make TSCanvas scale-aware in a way that the drawings fit to the scale instead of first drawing and then scaling afterwards? The control elements (e.g. toolbar) do consider the scale factor and are drawn perfectly but the TSCanvas is rather blurry.
@t2b3 the original post asked about Windows I believe, and your screenshot appears to be from Linux, but yes, that certainly looks terrible. The question is where/how this scaling is happening, since I am certainly not doing any scaling in my code. It is possibly wxWidgets doing this automatically on Linux for HiDPI, or worse, it is the underlying GTK implementation.
See the code here: https://github.com/aardappel/treesheets/blob/88966662d47db5d7f41711daa53c5bfa546cc217/src/myframe.h#L126-L148
What does this print on your machine? Maybe there's something Linux specific we can do there. Are you using the absolute latest wxWidgets?
Hello @aardappel
Thanks for your reply. I rebuilt Treesheets with debug symbols and ran gdb
. This is what I got:
❯ gdb $(which treesheets)
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/treesheets...
(gdb) break myframe.h:144
Breakpoint 1 at 0xdeb9d: file /usr/src/debug/treesheets/src/myframe.h, line 150.
(gdb) r
Starting program: /usr/bin/treesheets
This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.archlinux.org
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff15ff6c0 (LWP 36614)]
[New Thread 0x7ffff0dfe6c0 (LWP 36615)]
[New Thread 0x7fffebfff6c0 (LWP 36616)]
[New Thread 0x7fffeb7fe6c0 (LWP 36617)]
21:20:44: wxWidgets 3.2.1
21:20:44: locale: en_IE.UTF-8
21:20:44: content scale: 2.000000
Thread 1 "treesheets" hit Breakpoint 1, treesheets::MyFrame::MyFrame (this=0x555555a5b3a0, exename=..., _app=0x555555978d40) at /usr/src/debug/treesheets/src/myframe.h:150
150 /usr/src/debug/treesheets/src/myframe.h: No such file or directory.
(gdb) print csf
$1 = 2
(gdb)
Some more background information: For this scenario, I am running Treesheets in a Wayland environment with the WXWidgets 3.2.1 - GTK3 backend (GTK: 3.24.34) under the sway compositor / wlroots library (development versions / current git) with the scale factor 2.0.
The variable csf
is the same as the scale factor applied by the compositor.
This can be assured e.g. by changing the scale factor by running
swaymsg output DP-1 scale 2.0
before running Treesheets in the debugger. Then csf is 2. swaymsg output DP-1 scale 3.0
will result in csf
equaling to 3.
You shouldn't need gdb
, it should print content scale: 2.000000
normally?
But either way, it looks like my comment in the code is outdated, and the 2
is correct. However the csf
variable is used only for scaling bitmaps, not text. The fact that your text is from a half size render is not explained by this code. Like I said, that may be wxWidgets or GTK doing scaling without asking..
You shouldn't need
gdb
, it should printcontent scale: 2.000000
normally?
Thank you for your very fast reply! Yes, it does.
For Wayland under Linux, I solved the problem in the following way: (Direct painting instead of Bitmap buffering, like for MacOS)
diff --git a/src/mycanvas.h b/src/mycanvas.h
index 9554d12..459b266 100755
--- a/src/mycanvas.h
+++ b/src/mycanvas.h
@@ -30,6 +30,8 @@ struct TSCanvas : public wxScrolledWindow {
void OnPaint(wxPaintEvent &event) {
#ifdef __WXMAC__
wxPaintDC dc(this);
+ #elif __WXGTK__
+ wxPaintDC dc(this);
#else
auto sz = GetClientSize();
if (sz.GetX() <= 0 || sz.GetY() <= 0) return;
@t2b3 at least on Windows, that causes lots of flickering when scrolling and doing other operations (the wxBufferedPaintDC
below implements double-buffering).. can you try scrolling a large document with and without that change? Any flickering?
@t2b3 I guess if it does flicker, the other thing to try is what happens if you make the wxBitmap
twice as big.
@t2b3 at least on Windows, that causes lots of flickering when scrolling and doing other operations (the
wxBufferedPaintDC
below implements double-buffering).. can you try scrolling a large document with and without that change? Any flickering?
Thanks for your reply!
No flickering experienced so far, see video: https://user-images.githubusercontent.com/3286756/196776574-00ab8c5b-4a1a-433f-9061-cdd815cee398.mp4
Note: Video had to be downscaled due to attachment restrictions.
@t2b3 at least on Windows, that causes lots of flickering when scrolling and doing other operations (the
wxBufferedPaintDC
below implements double-buffering).. can you try scrolling a large document with and without that change? Any flickering?
What do you think about making it Linux specific so that the Windows build built against wxGTK continues working as before?
diff --git a/src/mycanvas.h b/src/mycanvas.h
index 9554d12..2a6313b 100755
--- a/src/mycanvas.h
+++ b/src/mycanvas.h
@@ -30,6 +30,8 @@ struct TSCanvas : public wxScrolledWindow {
void OnPaint(wxPaintEvent &event) {
#ifdef __WXMAC__
wxPaintDC dc(this);
+ #elif __LINUX__
+ wxPaintDC dc(this);
#else
auto sz = GetClientSize();
if (sz.GetX() <= 0 || sz.GetY() <= 0) return;
Ok, so maybe GTK does its own double-buffering already, so we can merge your patch. Want to make a PR or shall I merge it?
Yes, Windows has to keep working as-is. It can be __WXGTK__
since we wxWidgets doesn't ever build with GTK on other platforms, and thats the define we use elsewhere.
Ok, so maybe GTK does its own double-buffering already, so we can merge your patch. Want to make a PR or shall I merge it?
Yes, Windows has to keep working as-is. It can be
__WXGTK__
since we wxWidgets doesn't ever build with GTK on other platforms, and thats the define we use elsewhere.
Hi Wouter, I would like to ask you to merge the suggestion directly then into your Git tree.
Thanks in advance and keep up the good work, it is a pleasure to store information in the grids with Treesheets!
Kind regards, Tobias
Hi,
I'm running TreeSheets on a HiDPI display.
TreeSheets is usable, but not very attractive: tiny icons, text in search field too low, etc.
I can't find a good Windows' Compatibility–HiDPI setting, either.
Is that something you could improve without too much effort?
@th
Note: Microsoft has documented its HiDPI capabilities for Windows at Microsoft Win32 API Documentation
Side note: They implemented yet another API call DPI Awareness Context that only works starting with Windows 10.
Maybe commenting out all Windows-related DPI-related stuff in myapp.h
in the function OnInit()
and adding a manifest file treesheets.exe.manifest
side by side next to treesheets.exe
with the following content helps? (Not tested)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:application>
<asmv3:windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
Hi,
I'm running TreeSheets on a HiDPI display.
TreeSheets is usable, but not very attractive: tiny icons, text in search field too low, etc.
I can't find a good Windows' Compatibility–HiDPI setting, either.
Is that something you could improve without too much effort?