Performance Canvas.save() about chart-fx

[RalphSteinhagen]

@dlemmermann, as always, thanks a lot for your suggestion! I will look into and benchmark this.

Thanks also for your interest and your endorsement.

[RalphSteinhagen]

Hi again,

I gave it a shot and while I hoped it would -- it does not seem to improve the plotting performance. See the attached performance plot (25 Hz update rate) and committed concept branch for details (will leave this branch for a while for others to explore further). It seems that the remaining 10% load especially for plotting only a few data points seems to be within JavaFX itself.

N.B. I changed the GraphicsContext's .save() and .restore() operations to the recursive variant as suggested above in -- what I initially believed was the main "hot spot" -- AbstractAxes as well as the various performance-critical renderers (see committed branch).
I kept them though at least in the renderer' render(GraphicsContext gc, ...) routines to ensure that potential context forward/unrolling bugs are not propagated beyond the renderer boundaries and because these operations would be executed only once per repaint.
IMHO Swing used to be a bit faster in that domain because it could push those precious bytes with a whole lot less unnecessary double->float->int conversions before these bytes arrive in the GPU engine.

If I'd had the time, I'd compare and rewrite the GraphicsContext of JavaFX to the one used in Swing and also tune some of the other operations (but that would IMO involve some JavaFX GC API changes).

Thanks again @dlemmermann for diving deep into our codebase. It's always appreciated to get some expert Java veteran input on things.

[RalphSteinhagen]

closing this. GraphicsContext save/restore calls did not appear to be hot-spots. Kept them for readability and keeping GraphicsContext changes local for the given code segment.