AxisSynchronizer revalidation not work after zoom-in/revert

[raven2cz]

I recorded video, it is attached on my cloud here:

https://1drv.ms/u/s!Aq_X66v0FnfLjZdPclqy1a4O5o-Mqw?e=erYXZF

I want to continue with few points to financial part, but I reach one problem, which will be much more faster to discuss and solve with us.

According to video, AxisSynchronizer or my second alternative solution (inside video) are working but the problem is zoom-in, zoom-restore. The axis event change is called correctly, but the invalidation or repainting of chart never happen. The situation is very similar with another axis changes, but this change has some internal bug for revalidation and repainting.

Can you look on it, and try to find some easy solution how to repaint the chart, because you can see that the axis are already correctly modified, after just mouse hover the axis slider, it is correctly repainted to correct axis range. Thanks for help.

[RalphSteinhagen]

@raven2cz sorry for the late reply. We were on our annual hiatus.

This is -- unfortunately -- a known problem of the scene graph update cascade that for large trees and (some) unavoidable cyclic dependencies cause avalanches of -- often unnecessary -- update requests that reduce the overall performance.
We thus added early-on a rate-limiter in most renderers that accumulate the update requests, suppresses new ones if they arrived within 20-40 ms of the one that last triggered a re-paint, and then re-issue a single re-paint after the grace period has expired. This works for most cases but as you observed not for all ... :-(

For an illustration of the chart graph hierarchy have a look at this example.

The central Canvas, each axis, legends, etc. are -- in a clean JavaFX fashion style -- managed by container pains (GridPanes, [V,H]Box etc.). This allows a lot flexibility and easy extensions for non-lib developers but for larger or fast updating graphs adds some complexity w.r.t. the redraw, ie. whenever one of the components changes, all other components need to be resized, potentially changing axis limits, labels, etc. that need to be re-computed and re-drawn. This problem isn't per se a JavaFX problem (other libs have the same issue) but because of re-drawing is very expensive in JavaFX (compared to Swing or other non-Java UI kits) this becomes more a limiting issue.

One of the envisaged/recommended solutions is to reduce the scene graph tree/hierarchy depth and to manage at least the axis, canvas, and related updates in the same JavaFX node. This should prevent most of the costly cyclic dependencies (the cause of most of the missing re-paint issues) and also improve the overall performance.

There are also some related 2D/3D plot enhancements but we, unfortunately, did not find the time to get this into production yet.

[RalphSteinhagen]

@raven2cz does this problem still persist with the 11.3.1 release?