Sun 18 Dec 2016 02:29:04 PM UTC, comment #21:
Hi,
I just tested the patch on Qt 5, macOS, and a HiDPI (including the patch added via homebrew/science/octave)
It works fine for plotting points, but does not work for imagesc and the colorbar:
numberPoints = 100;
imagesc(rand(numberPoints));
hold on;
plot(1:numberPoints,numberPoints*rand(1,numberPoints),'.')
colorbar;
A fix is highly appreciated!
Thanks a lot for your efforts!
Regards,
Stefan
(file #39268)
|
Thu 17 Nov 2016 08:20:06 PM UTC, comment #20:
I have no access to macOS.
I am simply offering a review of the patch from my perspective, building Octave on Debian with either Qt 4 or Qt 5.
Yes a read-only internal-use (double-underscore) property in the root graphics object sounds like a good idea to me, that way it could more easily be queried in the interpreter as a side benefit.
|
Thu 17 Nov 2016 05:03:08 PM UTC, comment #19:
Mike Miller, can you confirm that the scaling problem happens on OSX with Qt4.8? This problem wasn't happening back with 4.0.3 provided by Homebrew, but I wasn't sure if it started happening because of the switch to Qt5 or if there was a change in Octave.
If you are also seeing the scaling issues with Octave 4.2 and Qt4.8, then I can try to come up with a solution that checks the Qt version and gets the screen scaling appropriately.
Do you have a suggested as to where to keep the screen scaling? We could have it as a property in the root graphics object. Does that seem like a better solution? Or, I could make it a non-public static variable and write accessors for it. I am open to what others think is best.
|
Thu 17 Nov 2016 08:03:57 AM UTC, comment #18:
The patch is already shipped with the homebrew 4.2 release (with small modifications such that it applies to the devel and release versions) [1]. So, I can confirm that it works.
Sebastian
|
Thu 17 Nov 2016 04:14:43 AM UTC, comment #17:
This patch needs some style fixes to conform to Octave coding standards. It will also not compile with Qt 4.8 because the devicePixelRatio property was not added until midway through the Qt 5 development series. I also think a public static variable (essentially a program-global value) in the gh_manager class is probably not the best way to store the scaling factor. If someone with Qt 5, macOS, and a HiDPI display wants to test to see if the patch works functionally please do.
|
Tue 08 Nov 2016 07:47:08 AM UTC, comment #16:
Sorry to keep posting, but I stink at making patches. This one has all the fixes as the previous patch, but is against the HG tip. The last patch was missing the #include of QApplication.
(file #38902)
|
Tue 08 Nov 2016 06:59:43 AM UTC, comment #15:
OK. I created an updated patch that fixed the problems with the last patch. I don't know what you all think the best way to keep track of the screen scale. I added it as a static member variable of the gh_manager class.
This should take care of both scaling the plot area for retina displays, ensure single markers are plotted in the correct location, and it scales the axes marker text sizes and the xlabel, ylabel, title, and legend text sizes.
It shouldn't affect a non-retina display because the scale factor will always be 1.0.
(file #38901)
|
Mon 07 Nov 2016 07:13:27 PM UTC, comment #14:
That patch I submitted still has big problems. It gets the plot to fill the entire axis, but now the plot coordinates are all messed up.
For example, I tried to
plot(0,0,'ro');
and it puts the marker at (-0.66, 0.58) according to the axis labels.
|
Mon 31 Oct 2016 03:25:48 PM UTC, comment #13:
I also observe the gui freeze when exiting. However, I have found that if I do a "close all" before calling exit that it doesn't seem to happen. I think that could probably help narrow down what is causing the freeze.
|
Sat 29 Oct 2016 09:51:12 AM UTC, comment #12:
This is already a huge step forward. Thanks! I am looking forward to include the patch in the 4.2 homebrew formula (since it will be to late for the official release).
Sebastian
P.S. the octave gui freezes on exit when using homebrew's qt5. Do you observe
the sane?
|
Fri 28 Oct 2016 05:46:57 PM UTC, comment #11:
Here is a patch that is a beginning to fixing the problem. This fixes the problem of the axis size and axis label scaling. I have another patch that fixes the font size scaling for other text object, but the problem is that they are overlapping the axis label. I suspect there are going to be a ton of places where position/size will need to be scaled by the screen scale.
I also don't know the guts of the handle graphics subsystem well enough to have added another property. I suspect we want the screen scale to be a top-level property, rather than a variable in gl_renderer and GLCanvas like I did in this patch.
I can continue to work on this, but was wondering if the the handle graphics system is abstracted enough that there are easy-to-find places where screen_scale should be applied?
(file #38835)
|
Thu 27 Oct 2016 06:13:44 PM UTC, comment #10:
This quick fix for the problem may be as simple as setting the viewport correctly based on the Retina size in pixels.
See http://stackoverflow.com/questions/25230841/how-to-find-display-scaling-factor-on-retina-4k-displays
and
https://forum.qt.io/topic/53059/qt5-and-opengl-with-a-mac-retina-display
I really need to figure out how to get homebrew to build from a local code location. I can't ever seem to get the patches and configure parameters right if I try to do it manually.
|
Fri 21 Oct 2016 08:59:24 PM UTC, comment #9:
I just realized that Matlab has the same issue: https://de.mathworks.com/matlabcentral/answers/241982-plots-are-shown-as-upper-left-cropped-on-osx-in-2015b
|
Sun 09 Oct 2016 07:06:54 PM UTC, comment #8:
Yes, we are trapped: octave with qt5 is not tested well but qt4 is not supported anymore since 2014 (with an extension to 12/2015). It does not compile on recent Macs without ugly hacks. Some package managers dropping support since nobody is officially fixing qt4 (according to homebrew maintainers there are a couple of severe unfixed security issues).
I have actually disabled the GUI in homebrew alltogether because of this :(
Sebastian
|
Sun 09 Oct 2016 05:58:04 PM UTC, comment #7:
Sebastian, I am surprised that people propose here and there to distribute Qt5 builds. Considering the first Octave/Qt5 binaries have come out a few weeks (mounth?) ago on linux and Mac do you think this a sufficient amount of time/testing?
At least this very bug shows that being able to build Octave with Qt5 is not the end of the story.
|
Sat 08 Oct 2016 01:26:29 PM UTC, comment #6:
I have just upgraded to 4.2.0rc2, qt 5.7.0 on macOS Sierra. The problem is still there and make plotting really annoying. Is anyone working on this? Can I help debugging, testing etc.?
|
Wed 14 Sep 2016 05:00:07 PM UTC, comment #5:
Retitled for easier searching. There have also been bugs reported about similar scaling issues on Windows systems with high resolution monitors and HiDPI scaling enabled.
|
Wed 14 Sep 2016 03:20:20 PM UTC, comment #4:
FLTK is not affected, see attached images. Regarding "QWindow::devicePixelRatio ()": I think so too. I added a possible fix for the retina icon bug 46723 [1]. However, the plotting backend is beyond my skills :)
[1] https://savannah.gnu.org/bugs/download.php?file_id=38206
(file #38506, file #38507)
|
Wed 14 Sep 2016 02:59:04 PM UTC, comment #3:
Thanks, are you able to test fltk in pure cli mode (launched using "octave -cli" or "octave --no-gui-libs") with this retina display. Does it suffer the same issue?
In Qt5 the way do detect the scale factor seams to be the use of QWindow::devicePixelRatio ().
|
Wed 14 Sep 2016 02:41:19 PM UTC, comment #2:
The value is between 149 and 114, see images attached (I used the monitor settings "default" and "more space"). However, in both cases the drawing area is too small by a factor of 2.
Sebastian
(file #38504, file #38505)
|
Tue 13 Sep 2016 09:05:40 PM UTC, comment #1:
According to this [1] I understand that on mac, even though HDPI resolution is hidden to the developper by the use of device independent pixel units (for widgets and graphics views), pixels in an opengl scene are still screen pixels:
IIUC, we should detect such high dpi screens on Mac and scale distances (and font size when expressed in pixels) in opengl by a factor of 2.
Sebastian, what does "get (0, 'screenpixelsperinch')" return?
[1] http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
|
Sat 10 Sep 2016 03:51:42 PM UTC, original submission:
I see wrongly scaled plot windows on my Mac when using the native qt5 backend. This might be due to "Retina" dpi settings of qt/Mac. I am not sure if other platform have similar problems? Issue 46723 might be related, [1].
[1] https://savannah.gnu.org/bugs/?46723
|