2D charts should have a consistent layout when switching from HiDPI to no HiDPI

[jzy3d]

State of layout in different cases

Native hidpi

The bar of the colorbar as well as the margin are thiner with HiDPI, according to pixel scale.

Native no hidpi

EmulGL hidpi

EmulGL no hidpi

Requirements

• 2D view margins should not be affected by HiDPI.
• 2D Layout debugger should properly draw dimension when used in a native or emulgl overlay (View2DLayout_Debug).
• Colorbar width should not be affected by HiDPI (see AWTColorbarImageGenerator.getScaledBarWidth() for a fix).
• Colorbar space to chart should be the same for EmulGL and Native charts.

2D View layout (in 2.1.0)

Colorbar layout (expected in this ticket)

Causes of the differences

• EmulGL chart viewport = full canvas (EmulGLViewAndColorbarLayout), on native, only a slice, the other one is for colorbar (ViewAndColorbarLayout)
• Image and text position for EmulGL is in "classic" coordinates, ignoring HiDPI resize, whereas GL uses a larger canvas size. This lead to special cases in AWTNativeViewOverlay vs EmulGLViewOverlay, in AWTImageRenderer (with IF about native), in AxisLabelProcessor, etc

Related TODOs

• Let chart.getColorbar() return an IColorbar which includes everything needed to avoid casting to AWTColorbarLegend everytime. Especially get/setFont get/setMargin
• Understand why updating font requires two rendering to get properly layout.
• Let EmulGLChartFactory instanciate as many charts as needed (deal with the internalCanvas and internalPainter members in EmulGLPainterFactory).
• provide a chart.getLayout() returning ChartLayout, a facade to all layouts (AxisLaout, View3DLayout, View2DLayout, ViewportLayout, LegendLayout, LineLegendLayout) and rename ViewAndColorbarsLayout to ViewAndColorbarsProcessing to comply to View2DLayout and View2DProcessing.
• Remove all calls to colorbar setMinimumSize / getMinimumSize / setShrinkColorbar / isShrinkColorbar

[jzy3d]

Relates to #249

[jzy3d]

#278

[jzy3d]

Remarks

• 3D rendering : When pixelscale > 1, the number of pixels of the native CanvasAWT is multiplied by pixelscale, hence the image of the colorbar is equally magnified. Said differently, when opening a JFrame at 600x600, the actual viewport size on a Retina display with pixelScale=2 will be 1200x1200.
• 2D rendering : Overlays, colorbar generators etc must be aware of pixel scale to properly size and layout items. E.g. the bar of a colorbar must be scaled in order to appear the same size.
• 2D text rendering : text renderer by JOGL TextRenderer must have the font size scaled to have the text appear the same size (done by HiDPIProportionalFontSizePolicy). Text rendered by EmulGL (which relies on Graphics2D.drawString) does NOT need to be scaled as the JVM will handle this already.
• As a consequence, overlays such as View2DLayout_Debug deal differently with Native and EmulGL : EmulGL requires the text to be unscaled (since the base font was scaled).

Classes working with pixelScale

• All canvases inform view of current pixel scale
• GL Viewport is scale on native, but keep the same size on EmulGL
• View, View2DLayout, View2DProcessing (EmulGL differs to native with (1) add a right margin based on legend width, (2) scale vertical tick and axis text width), View2DLayout_Debug (debug with an overlay : native scales graphics2D by 1/scale, emulgl makes scales font by 1/scale)
• ViewAndColorbarsLayout has no reference to scale, but EmulGLViewAndColorbarsLayout computes colorbar margins with scale.
• AWTColorbarLegend, AWTColorbarImageGenerator (has a flag dedicated to EmulGL scaling, use scale to process colorbar width), AWTImageViewport
• AWTNativeViewOverlay (scale and unstretch graphics2D), EmulGLViewOverlay (renders in a scaled image with a scaled graphics2D)
• HiDPIFontSizePolicy (multiply font height by scale.y)
• AxisTickProcessor
• AxisLabelProcessor has a particular case for EmulGL case that is shifted a bit when layout is NOT horizontal)
• ICanvasListener, PixelScaleWatch, CurrentScreenWatch
• jGL.GL

Differences between jGL and Native can be found by looking at callers of Canvas.isNative()

[jzy3d]

Classes working with pixelScale

• All canvases inform view of current pixel scale
• View, View2DLayout, View2DProcessing, View2DLayout_Debug
• ViewAndColorbarsLayout, EmulGLViewAndColorbarsLayout
• AWTColorbarLegend, AWTColorbarImageGenerator, AWTImageViewport
• AWTNativeViewOverlay
• HiDPIFontSizePolicy
• AxisTickProcessor
• AxisLabelProcessor
• ICanvasListener, PixelScaleWatch, CurrentScreenWatch
• jGL.GL

Differences between jGL and Native can be found by looking at callers of Canvas.isNative()

[jzy3d]

Integration tests baselines show that we now have a consistent layout among windowing toolkits, resolutions (HiDPI/not), and OS (macOS 10, macOS 11, Ubuntu, Windows 10)

Exception on Windows+AWT+HiDPI

due to a known bug (#101) for which a workaround was provided.

We are for now able to combine all these HiDPI layout computation with Windows fix but can not find a way to let ViewAndColorbarsLayout deal with the colorbar height in the case of Windows+AWT+HiDPI.

Swing case on Windows (correct)

AWT case on Windows (correct on width, incorrect on height)

Possible long term fix

• Let the colorbar rendering be made in pure OpenGL, instead of rendering an image with AWT Graphics2D and then copy the image to an OpenGL viewport.
• Evaluate another GL binding (LWJGL or Panama).