octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #49053] figure scaling issue with Qt 5 on macO


From: Rik
Subject: [Octave-bug-tracker] [bug #49053] figure scaling issue with Qt 5 on macOS with Retina / HiDPI scaling
Date: Wed, 31 Jan 2018 20:53:49 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #95, bug #49053 (project octave):

I tried the latest patch with Linux and it appears to mostly work.   When
shifting a figure from the HiDPI display to a normal one the axes containing
the plot is shrunk, however the figure itself is not, so that when you do any
operation the axes is autoscaled to match the figure size which is large.

That might be something to do with the version of Linux I am running which is
rather old (Mint 18.1 based on Ubuntu 2016.04).

However, the patch has gone backwards from a coding perspective.  There are
numerous tabs, the alignments that I contributed in comment #86 are gone, and
there are many cuddled parentheses for function calls which is not the Octave
convention.

This is a major new feature so there should be an announcement about it added
to the NEWS file.  It should please a lot of people.

There is still a problem with the calculated "Extent" property for text
objects.  Somewhere in the code there needs to be a division because the
calculated value is off by about the scale factor I use for the HiDPI
display.

Is there any performance issue associated with having the DPI on a per-figure
basis?  Is the value cached somewhere so that it only needs to retrieved when
the figure is created or changes screens?  Caching within a property value of
the figure isn't necessarily that fast.  Property class objects are huge and
unwieldly.  As one example,


+    virtual double devicePixelRatio (const graphics_object* go)
+    {
+      graphics_object fig = go->get_ancestor ("figure");
+      const figure::properties& fp =
+       dynamic_cast<const figure::properties&> (fig.get_properties ());
+      double devicePixelRatio = fp.get___device_pixel_ratio__ ();
+      return devicePixelRatio;
+    }


Rather than get all the properties, if you have a valid graphics_object it
might be simpler to just use get()


+    virtual double devicePixelRatio (const graphics_object* go)
+    {
+      graphics_object fig = go->get_ancestor ("figure");
+      return fig.get ("__device_pixel_ratio__").double_value ();
+    }


That same coding strategy can be used in multiple places, but should probably
be benchmarked just to make sure it isn't slower.

I think you can avoid work when shifting figures between screens and there is
no DevicePixelRatio support.  For example,


+  Figure::figureWindowShown ()
+  {
+    figure::properties& fp = properties<figure> ();
+    QMainWindow *win = qWidget<QMainWindow> ();
+#if defined (HAVE_QSCREEN_DEVICEPIXELRATIO)
+    QWindow* window = win->windowHandle ();
+    QScreen* screen = window->screen ();
+    fp.set___device_pixel_ratio__ (screen->devicePixelRatio ());
+
+    connect (window, SIGNAL (screenChanged (QScreen*)),
+         this, SLOT (screenChanged (QScreen*)));
+#endif
+
+  }


If HAVE_QSCREEN_DEVICEPIXELRATIO is not defined, is there any reason to even
get the properties and window?  Why not put the entire function body inside
the #if block?



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49053>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]