kasemir / org.csstudio.display.builder

Update of org.csstudio.opibuilder.*
Eclipse Public License 1.0
2 stars 10 forks source link

Optimize representations by using unmanaged nodes #489

Closed kasemir closed 5 years ago

kasemir commented 5 years ago

Running examples/template_and_script/many_instances.bob, with script changed to create 2000 instances, updates are very jerky. This example contains mostly text update widgets which update their border a lot because of alarms. JProfiler shows that UI thread time is mostly spent in Region.setBorder() triggering Node.notifyParentOfBoundsChange.

By updating the Node used by the TextUpdateRepresentation to be unmanaged, since we're setting the location and size anyway from the Model, CPU load is a little lower, but more important the UI updates are more frequent.

--> Update TextUpdateRepresentation to use unmanaged node, see if other widgets could also benefit.

claudio-rosati commented 5 years ago

Interesting finding. I'll check up the other widgets.

kasemir commented 5 years ago

Some more detail:

When many text update widgets show something like sim://noise(-5,5,0.1) that causes the alarm sensitive border to change all the time, the UI thread is very busy in Region.setBorder() triggering Node.notifyParentOfBoundsChange:

man2

When I update the TextUpdateRepresentation to use label.setManaged(false), that means it also needs to call jfx_node.resize instead of jfx_node.setPrefSize, and after updating the text, I need an explicit jfx_node.layout() because the node is no longer managed by its parent. As a result, it's now spending less time in the UI thread, and the time it does spend there is with the expected handling of the text changes:

noman2

I'll check some other widgets.

Operationally, I'm not sure if it will make a big difference. Our beam line displays are mostly occupied with drawing XY and image plots, where most of the work is performed in background threads, and on the UI thread it's handling the low-level pixel drawing triggered by ImageView.setImage. I don't think that can be avoided, all you can do is adjust the throttling preference.

claudio-rosati commented 5 years ago

The following synoptic OPI I've made for one of our groups is made exclusively with Display Builder (I mean no Symbol widgets, every valve is an Embedded Display and the content uses only graphics widgets). It was the first (and not the more complex) of a series of such synoptic OPIs I was asked to do for various groups.

I think they will benefit of the change.

synoptic-3

kasemir commented 5 years ago

For TextUpdate, LED, ByteMonitor widgets where the border often shows an alarm, I see an improvement making them unmanaged, then basically calling resize instead of setPrefSize, and for labels requiring layout after changing the text. I can verify with newly added template_and_script/many_xxx.bob examples.

For plot widgets I see no difference, but updated those anyway because the scene graph inside those plot widgets does change when toolbar is opened/closed etc.

For static widgets like labels and lines I have nothing to test in the profiler, since they are static on the screen, not using any CPU at runtime. So not updating those.