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

[Alexander Scherbatiy]

  Could you add a test to the fix?

  Thanks,
  Alexandr.

On 1/30/2014 5:49 PM, Anton V. Tarasov wrote:
> 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.