Performance difference between THREADED_REDRAW and DIRECT_REDRAW mode

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.