line start (from NaN) rendered incorrectly

[ennerf]

@RalphSteinhagen asked for a video in #26. A video of Scope with the latest dev snapshot is here: https://youtu.be/SXEf-2NyUlw

While recording it I noticed two more minor issues:

• in 01:15 I'm starting to send commands, which changes the positionCmd (dashed) from NaN to the current feedback value. I'd expect the line to start at the first valid point, but for some reason it starts from the bottom of the screen. (The bottom is cut-off, so it's not visible, but it did come in from the bottom edge)

• In 03:12 I'm trying to pan, but it's panning much faster than it should. I've seen this occasionally in the past, but I haven't found a reliable way to reproduce it yet.

The static chart has about 2 million datapoints total (3x 642.875). Kudos btw. for making that work so well... the previous version sometimes crashes when loading logs like this :)

[RalphSteinhagen]

Thanks a lot for the video! Looks very interesting. 👍

[..] I'd expect the line to start at the first valid point, but for some reason, it starts from the bottom of the screen. (The bottom is cut-off, so it's not visible, but it did come in from the bottom edge) [..]

For the time being that's was/is the necessary, defined and intended behaviour (ie. not 'incorrectly' but 'by design').

A bit of history/rationale on this:

more..

_we noticed that the JavaFX rendering pipeline crashes when fed with too many NaNs. In the olden days (Swing) NaNs used to stop/restart the polyline rendering. Since we didn't want to also touch the C/C++ part of the JVM, we tried to reimplement the line start/stop functionality in the user code but the performance was horrid. Thus we deliberately dropped this and decided to draw vertical 'NaN' values to the bottom of the canvas which works for our use cases._

Unless things have changed, this may be a necessary compromise (N.B. backward comatibility to JDK8 & and JDK11+JFX12 is for the time being an aspect in our community).

Nevertheless, you may overwrite the corresponding routines. The code that would need to be modified is here and here (essentially just comment out).

regarding performance: we are reworking the hash map and recomputation of some aspects of the axes and gained a bit (not yet committed, but who would have thought that the JDK ConcurrentHashMap is slower than a custom written routine... 😮 ).

[ennerf]

Thanks for the info. I don't remember seeing anything related to this in the changelogs for OpenJFX 12 and 13. Have you considered filing a bug report? Now that OpenJFX is independent of the JDK there is a good chance that this could be addressed comparatively quickly. You could always add a runtime constant for maintaining backwards compatibility.

The JDK implementations are general purpose and may have to support legacy interfaces that are difficult to implement concurrently. If you have a very specific use case there are often much better alternatives such as the specialized queues in JCTools. Apparently they have some maps as well, but I've never tested them.