Use VolatileImage for back-buffers to allow hardware-accelerated rendering

[hfmkwi]

Summary

This partially fixes Ticket #20366 wherein rendering is abysmally slow, especially on HiDPI systems. Current behavior uses a double-buffer strategy with BufferedImages, forcing virtually all rendering into software loops.¹ The bespoke HiDPI buffer scaling with AffineTransforms compounds this performance degradation.² Performance seems to suffer exponentially with each additional layer regardless of its data; imagery tile layers seem to contribute the most.³

I’ve switched the buffers to VolatileImages, so the renderer can now defer to hardware routines where possible. This also defers HiDPI-scaling to the hardware surface, eliminating the need for the existing software one. The performance improvement is most obvious when running JOSM with a hardware-accelerated pipeline and

1. panning an non-trivial OSM data layer with labels disabled;
2. panning an arbitrary number of enabled imagery layers;
3. working with area fill enabled; or
4. working at high zoom levels.

This cannot convert some inherently software-based render operations like

• Graphics2D canvas/text anti-aliasing;
• GlyphVector-based text rendering; and
• alpha compositing (and whatever else I couldn’t find).

These ought to be refactored to take advantage of the equivalent hardware routines, if possible. If not, then the user should have finer control over these (e.g., rendering hints).

Miscellanea

This also fixes a couple of performance regressions:

• MapView was marked as a transparent component; and
• hovering over an OSM primitive would immediately invalidate the layer, even if inactive

Footnotes

1. See Oracle docs. ↩

2. Incidentally, this is probably why the recommendation to run with -Dsun.java2d.uiScale=1 was a suggested solution, since the resulting AffineTransform would’ve been the identity matrix. ↩

3. Stacking imagery layers very quickly destroys the frame rate. ↩

[stoecker]

The virtual desktop is not static. It can change (i.e. add another monitor).

[hfmkwi]

This is an issue I thought about for a while, since there's no non-trivial way of solving it.¹ There’s no public interface for listening to complete GraphicsEnvironment/GraphicsDevice changes.²

I could have the virtual desktop dimensions recalculated on
every GraphicsConfiguration change. This might work if

• GraphicsEnvironment.getScreenDevices() always returns a live view of current screen devices; and
• stale screen devices are immediately evicted alongside their GraphicsConfigurationss.

These were my initial assumption—but I can’t find any supporting documentation. In testing, the component GC is invalidated when it’s moved between screen devices. I think this is reasonable enough evidence for my assumption. For now, I can apply that solution, since it seems the best compromise.

Footnotes

1. At least, there’s no tidy solution I’ve found yet myself. ↩

2. I could use reflection to get the internal one, but then I’d be dealing with implementation details that would unnecessarily complicate this. I also can’t reliably test for these, and I doubt these are guaranteed compatibility with an arbitrary Java version. ↩

[stoecker]

Assumptions sound sane. Go for it and we'll hope it works fine. While I appreciate the improvement I fear the issues which changes to such a central component can bring. Especially the multiscreen stuff was very fragile a long time.

[hfmkwi]

I get the concerns: I’ve approaching this with multi-head setups in mind since I’ve been testing on one. There are some hardware pipeline idiosyncracies that might affect render speeds depending on which screen device the application resides,¹ but those seem platform- and pipeline-specific.² Generally, this setup should be correct for both single- and multi-head setups and for HiDPI setups.³

Footnotes

1. On my machine, at least, the D3D pipeline runs on all screens and VolatileImages are compatible only with their progenitor screen device, whereas the OGL one runs on display 0 only and the VIs appear to be resistant to that. ↩

2. Determining the actual renderer requires either a string comparison with screen device IDs or reflection to expose package-privage implementation details of the JDK ↩

3. Internally, SunVolatileImage appears to use a GC-compatible BufferedImage if something goes wrong with the hardware pipeline, falling back to the same setup as current. Also, this means null-checking the return value of createCompatibleVolatileImage is optional except in headless setups, but then MapView will skip creating those buffers and painting entirely. ↩

[stoecker]

VIRTUAL_DESKTOP_BOUNDS indicates it is static and unchangeable (constant). I think virtualDesktopBounds is better.

[stoecker]

One checkstyle:
src/org/openstreetmap/josm/gui/MapView.java:369:43: Missing space after ','

[stoecker]

Ok. I did a first test on my non-HIDPI screen using a larger data set and nothing else and simply move it around. With your patch it feels significantly slower.

[hfmkwi]

Ok. I did a first test on my non-HIDPI screen using a larger data set and nothing else and simply move it around. With your patch it feels significantly slower.

What render settings were your running with? Pipeline, anti-aliasing? Any sort of AA, text or canvas, is done entirely in software, and the JDK docs caution against mixing hardware- and software-based rendering to avoid performance degradation.¹ Maybe I should have the AA preferences in the GUI warn about this? As for the pipeline, assuming you’re on a Windows machine, using anything other than the DirectDraw/GDI one should significantly yield better frame times.²

Footnotes

1. In testing, enabling AA doubled render times when on the hardware pipeline. ↩

2. Strangely, in current JOSM, disabling DD with -Dsun.java2d.nodraw=true yields perceptually better render times. ↩

[hfmkwi]

If these changes are sufficiently intrusive, I could also move this code to an entirely separate renderer that overrides paint methods as applicable.

[stoecker]

I used default settings (Linux openSUSE), no special setup.

I think the first thing we need is proper profiling code which also outputs the relevant parameters (pre-patch and post-patch), so that we can compare number instead of feelings. We can then use a screen recorder and playback to compare identical situations.

Than we can check where the code improves situation and where it makes it worse. Based on that we can either fix introduced bugs or decide to make different code for different setups.