<Swing Dev> <SwingDev> [9] Review request: 8033233 [JLightweightFrame] support default JViewport BLIT_SCROLL_MODE

[Anton V. Tarasov]

Hi all,

Please review the fix.

jira: https://bugs.openjdk.java.net/browse/JDK-8033233
webrev: http://cr.openjdk.java.net/~ant/JDK-8033233/webrev.0

Here I'm duplicating JIRA:

The point of the fix is that it introduces a RepaintListener which can 
be added to a RepaintManager in order to get back notifications of 
repaints performed as BLITs. JLightweightFrame registers such a listener 
to its RM instance. JViewport is the source of those notifications. Now 
it works in default BLIT_SCROLL_MODE.

Shortly, the mechanism of repainting of a JLF is the following. Once a 
JLF's child component is requesting repaint, an appropriate repaint 
runnable is scheduled by the RepaintManager (RM). The runnable is then 
gets dispatched by the RM which calls the paint() method of the root 
component, that is the JLF. JLF overrides this method in the way that 
after all the painting is done (super.paint) it initiates a pixel bits 
transfer to the host application (e.g. SwingNode). In case of JViewport, 
when it works in the default BLIT scroll mode, scrolling of the 
JViewport doesn't lead to a repaint runnable being dispatched. Instead, 
JViewport immediately repaints its content (via blitting + repainting a 
dirty area) and then tells the RM there's nothing to repaint (so the 
runnable scheduled is just skipped). As the result, the JLF doesn't get 
any notification of the update.

As a workaround to this problem, JViewport had been forcibly switched to 
the BACKINGSTORE scroll mode, in which case it passes the whole 
repainting cycle.

Regards,
Anton.