[Octave-bug-tracker] [bug #49053] figure scaling issue with Qt 5 on macOS with Retina / HiDPI scaling

[John Swensen]

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

So I have a pretty minimally invasive example that stores the devicePixelRatio
for each figure independently. Here are some highlights of the required
changes:

1) graphics.in.h: create a __device_pixel_ratio__ in each figure object (I
figure we might as well call it what QT calls it, rather than screen_scale).
2) FigureWindow.h, FigureWindow.cc: Capturing the showEvent so that it can be
forwarded on to the Figure class for setting up the detection of screen
changes (QT doesn't let you connect to this signal until after the window has
actually appeared).
3) Figure.h, Figure.cc: When the window is first shown (from FigureWindow
showeEvent) and from connecting to the screenChanged event, we update the
__device_pixel_ratio__ in the properties associated with this Figure

This part is working great. Here is the problem I am having that needs input
from all of you. Because the devicePixelRatio is now stored in the parent
figure property, I need access to the parent figure in each drawing routine in
gl-render.cc

If you go look at the opengl_renderer::draw function in gl-render.cc, you see
that some of the draw functions takes the properties and the graphics_object
(see draw_uipanel and draw_uibuttongroup), but that most only take the
properties (see draw_figure, draw_axes, draw_line, etc).

So, my question is whether there is a compelling reason to not follow a
pattern where all of these draw_* functions that are called from
opengl_renderer::draw take both the properties and the graphics_object. That
way, in any draw_* function that needs the devicePixelRation, I can just call

graphics_object fig = go.get_ancestor ("figure");
like is done in opengl_renderer::draw_uipanel.

Thoughts, suggestions, and comments? This will make it so that transitioning
windows between screens with different devicePixelRatios will not mess up the
plotting.

    _______________________________________________________

Reply to this item at:

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

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