Java Magazine: Design Patterns by Andrew Benstock

Author:Andrew Benstock [Benstock, Andrew]
Language: eng
Format: azw3
Publisher: UNKNOWN
Published: 2018-12-02T16:00:00+00:00

The important detail here is to perform the coordinate transformations off the rendering thread.

behavior. This can be somewhat mitigated by wrapping the while loop in the thread-safe Platform.runLater() Runnable, which is commented out in the previous code. Doing so improves the performance as follows:

Total elapsed time: Total ns: 497896, 0:s:0:ms:497:us:896:ns Drew batch size of 56194 For a similar quantity of points, total execution time has shrunk from 24 ms to less than 1 ms. Don’t be fooled though: this reduced time is deceptive because what I have done is handed the workload to the JavaFX platform to manage and then execute at the next available rendering pass. This approach takes much less time than the original approach without runLater(), but now I am sending a large number of Runnables to the JavaFX platform for processing.

This solution scales well to the 10,000-point range. However, what if you want to add an order of magnitude and make it 100,000 points? Given all the coordinate transform math and other work being done, the time spent in each Runnable instance is too large. Further, given the high frequency of data bursts, there are far too many Runnable instances being sent to the JavaFX platform for processing. This pattern could potentially throw cryptic rendering exceptions, such as java.lang.InternalError: Unrecognized PGCanvas token: 64, when the underlying JavaFX engine cannot keep up.

Second Approach An alternative approach is a slight variation to the previous method. This implementation seeks to do as little as possible in the blocking Platform.runLater() Runnable. The code for this is shown toward the end of the following implementation of the drawNext_ArrayTransforms() method:

private int drawNext_ArrayTransforms() {

int size = pointQueue.size();

GraphicsContext g = canvas.getGraphicsContext2D();

//temporary arrays to hold the transformed canvas coordinates //Be sure to use primitive double type to minimize memory double[] xArray = new double[size];

double[] yArray = new double[size];

//loop across all available points by polling the concurrent queue for (int i = 0; i < size; i++) {

PointPojo point = pointQueue.poll();

//coordinate transformations stored in temporary arrays xArray[i] = transformXToScreen(point.x);

yArray[i] = transformXToScreen(point.y);

//encourage finalization of the object I polled

point = null;

}

//Using arrays to hold transformed coordinates allows me //to use a runLater() thread while minimizing blocking time Platform.runLater(() -> {

//The key is minimizing time spent in this blocking thread for (int i = 0; i < size; i++) {

g.fillOval(xArray[i], yArray[i], radius, radius); }

});

return size;

}

You will notice that I use a for-loop to poll objects from the concurrent queue. I could have used an iterator instead of the for-loop to process the available points. However, iterators take more than an order of magnitude longer than a loop that calls poll(), because the JVM Hotspot has not yet “warmed up” to the iterator bytecode and so it is not JIT’ed but rather would be interpreting each command.

The important detail to mention here is that the code in this alternative method performs the coordinate transformations off the rendering thread. Moving these time-expensive calculations off the rendering thread minimizes the time spent blocking in the JavaFX ren- dering thread. By minimizing the

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.