tmf: Fix unresponsive UI when mouse wheel zooming in TimeGraphViewer

tmf: Fix unresponsive UI when mouse wheel zooming in TimeGraphViewer

When developing the time graph marker axis, it was noticed under Windows
that there was a delay in painting the marker axis when compared to the
time graph state area. It seems that if a new redraw request occurs
while the time graph state area is being painted, the following control
in the draw order (the marker axis) is not painted before until the next
paint event. The visual effect is that the time graph state area follows
the user input while the marker axis does not update until the user
input stops.

The solution found was to call Control.update() on those parts, which
would block the UI thread until all parts have been painted.

However, under Linux this can cause pending user inputs to be queued.
While the time graph is painting, rapid mouse wheel scrolling queues
many MouseEvent that each individually trigger blocking paint events.
This also prevents many mouse wheel scroll events to eventually combine
into triggering a single paint event. After quickly scrolling the mouse
wheel many times then stopping, the user can see the queued events
triggering a multitude of paint events that can last a few seconds even
while there is no user input. Any new user input needs to wait for all
the queued paint events to be completed before being processed.

The blocking calls to update() are therefore removed. This can cause a
temporary visual misalignment under Windows, but this effect is much
less noticeable under Linux.

Change-Id: I12d3d17eff0d8a443822083e0aa2113c3b23fedc
Signed-off-by: Patrick Tasse <patrick.tasse@gmail.com>
Reviewed-on: https://git.eclipse.org/r/87246
Reviewed-by: Hudson CI
Reviewed-by: Bernd Hufmann <bernd.hufmann@ericsson.com>
Tested-by: Bernd Hufmann <bernd.hufmann@ericsson.com>