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

[Anton V. Tarasov]

Hi Alexandr,

Actually, we don't add tests against JDK issues related to 
JLightweightFrame... You can see that "swing-interop" tagged bugs are 
noreg-hard. There are two reasons, first is that they are indeed hard 
(possible, but requires additional efforts), second is that they require 
the host app, namely SwingNode. But we have some tests on the JFX side.

Thanks,
Anton.

On 1/30/14 6:18 PM, Alexander Scherbatiy wrote:
>
>  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.
>