esternin / eXtrema

https://www.physics.brocku.ca/Labs/extrema/
GNU General Public License v2.0
6 stars 1 forks source link

High dpi #30

Closed esternin closed 3 years ago

esternin commented 3 years ago

VZ, see my comments in the issue https://github.com/esternin/eXtrema/issues/19#issuecomment-840242954

Font size under Print is the only remaining issue, the rest is scaling fine on all DPI displays. VisWindow and EPS are a good match, on all DPI displays.

I left old code in, commented out, until the font size is fixed.

This is looking close to a release.

vadz commented 3 years ago

Sorry, I'm very, very lost here. I basically don't understand any of the changes done in this PR and I have serious doubts about their correctness.

Could you please explain what is the minimal test I can perform with the current main to see the problems in high DPI? I've tried @2yaxes but I don't actually see any problems with this, i.e. everything appears alright on the screen.

esternin commented 3 years ago

Hmm. That's not the case here. I checked out the main branch as it stands right now, and this is what it looks like on my 96x96 desktop: image

Repeating the same on a Chromebook, with its 2400x1600 LCD set at "100%" or "like 1200x800" looks like this: image

My entire set of high-dpi branch changes was to bypass the wx scaling mechanism, as written up in the wx book "Cross-Platform GUI Programming with wxWidgets" (I realized Joe basically followed exactly the examples from Ch.5, p.166) - because that method of scaling did not work.

Instead, I calculate the true scaling coefficient by taking the (xmin,ymin,xmax,ymax) in the graph units, and mutiplying it by the true size of the canvas, correcting as needed for Screen or Print dpi, and passing that as the actualScale in dc->SetUserScale(actualScale, actualScale);. Unfortunately, while all the graphical elements do get scaled correctly, the text size does not, it's way too small. I could not find a separate font scaling coefficient in wxWidgets, so perhaps it's a bug? I could not figure out a workaround, short of actually passing actualScale to every text-placing routine. The thing is, it is only needed during Print, and not Screen drawing.

esternin commented 3 years ago

Here's what our own GRA_postscript.cpp generates as .eps, and the result of the File->Print, to a .pdf of the same page size, again based on the main branch version, on the 96x96 Ubuntu desktop: image

vadz commented 3 years ago

OK, maybe I'm blind, but what exactly is wrong with the 2 Y-axes visualization? The only problem I see in this window itself is too much space left to the right of the tab, which is probably due to hardcoding 50 pixels (which becomes 100 pixels in high DPI), and I also see that the "Execute Script" dialog is broken in your screenshot (but not here somehow), but I'm trying to concentrate on one thing at a time and I thought there was a problem with the plot itself -- but I don't see it, neither on this screenshot, nor on my own high DPI notebook.

Could you please explain what exactly are we trying to fix here?

esternin commented 3 years ago

What do you mean?

We are trying to fix THIS https://user-images.githubusercontent.com/29458452/118316511-eac06880-b4c4-11eb-93fd-2a99914311a3.png

to make it look like THIS https://user-images.githubusercontent.com/29458452/118316396-c6fd2280-b4c4-11eb-8609-972d7916e760.png

Do you now see that the fonts are all wrong size, much, MUCH too large?

esternin commented 3 years ago

The space to the right of the tab does not bother me much, the "execute script" text size is mismatched to the size of the button into which it is meant to fit, this latter one may well also be related to the font scaling, but this is all minor.

Remember, the same script should produce the same-looking graph on any platform. Font that is 4% of the screen height (or width) shoudl remain 4% of the screen height (or width) no matter what the size of the canvas, and no matter what is the resolution of the device on which it is rendered. What I see on a high-dpi device is the text that is CATASTROPHICALLY too large, making the graph unusable.

esternin commented 3 years ago

this is what the main branch outputs - Screen and Print to pdf - look like on the "192"-dpi Chromebook. At least in my high-dpi branch the graphics are scaled correctly, and only the font scaling remains to be fixed. Here, we have issues with both. image

vadz commented 3 years ago

For the record, if I insert this debugging code:

diff --git a/src/Graphics/GRA_drawableText.cpp b/src/Graphics/GRA_drawableText.cpp
index acbb54b..5843b69 100644
--- a/src/Graphics/GRA_drawableText.cpp
+++ b/src/Graphics/GRA_drawableText.cpp
@@ -177,6 +177,7 @@ wxFont MakeFont( GRA_wxWidgets* graphicsOutput, GRA_simpleText* text )

   wxFont font( text->GetFont()->GetwxFont() );
   font.SetPointSize( h );
+  wxLogDebug("World height=%g, font height=%d", height, h);

   return font;
 }

I see the same output in both normal and high DPI (I'm running the same binary on local high DPI display or using a remote normal DPI X server), e.g. the first line (after executing @2yaxis) in both cases is

Debug: World height=0.17, font height=8

I wonder what does it give for you?