Performance difference between THREADED_REDRAW and DIRECT_REDRAW mode

Article ID: 2444
Last updated: 29 May, 2018
Article ID: 2444
Last updated: 29 May, 2018
Revision: 3
Views: 419
Posted: 03 Jan, 2013
by Dean J.
Updated: 29 May, 2018
by Gargani A.

Question

What is the performance difference between THREADED_REDRAW and DIRECT_REDRAW mode?

Answer

THREADED_REDRAW will stack the repaint requests. The repaint requests will be enqueued for the AWT/Swing Event Queue thread which is processed asynchronously. This mode shows good performance in the amount of CPU utilization on behalf of the redrawing, but at the cost of some performance in the delay between a redraw request and the actual change on screen. It is impossible to overload the CPU with redraw requests because the slower the painting gets due to complex graphic objects, the more repaint request are merged and thus time is saved.
DIRECT_REDRAW does the opposite. It optimizes the performance in the delay between a redraw request and the actual change on screen, but at the cost of performance in the amount of CPU utilization on behalf of the redrawing. This mode is very useful in animations and multithreaded situations where the AWT/Swing EventQueue thread is blocked for a long time. Where as in THREADED_REDRAW mode when this thread is blocked, repainting is kept on hold leading to poor performance in the delay between a redraw and the actual change on screen. However, the drawback is that you have to ensure that there are not too many repaint requests because this could overload the CPU making your application not as responsive.

Note: You can switch the mode by calling the setRedrawMode(int mode) method of IlvManagerView. The default mode is THREADED_REDRAW

This article was:   Helpful | Not helpful
Report an issue
Article ID: 2444
Last updated: 29 May, 2018
Revision: 3
Views: 419
Posted: 03 Jan, 2013 by Dean J.
Updated: 29 May, 2018 by Gargani A.
Also listed in


Others in this category