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

[Alexander Scherbatiy]

   The fix looks good for me.

   Just a minor comment. It seem that the condition in 
DefaultDesktopManager: "if (!floaterCollision) { .. } 
if(floaterCollision) {...}"
   is the same as "if (!floaterCollision) { ... } else  {...} ".

   Thanks,
   Alexandr.


On 1/31/2014 11:55 AM, Anton V. Tarasov wrote:
> Hi Petr,
>
> On 30.01.2014 18:16, Petr Pchelko wrote:
>> Hello, Anton.
>>
>> Great, you are removing the dirty JViewPort hack)
>>
>> I have one question: is JViewport a single place where we use the 
>> "blit" rendering?
>
> Yes, there's one more place - in DefaultDesktopManager. It BLITs on 
> dragging a JInternalFrame instance but only in FASTER_DRAG_MODE which 
> is not its default mode. I hadn't test it, but I tried. I switched the 
> mode and what I see is that w/o any modifications a dragged JIF is, as 
> expected, not repainted. I've put the notifications into the code. 
> This made a JIF instance repaint on drag. However, there's an issue 
> with the shadow. The shadow is not repainted, but background artifacts 
> instead. I didn't yet find the reason, I suspect there's some async 
> repaint which I probably don't catch.
>
> I suggest not to spend time in DefaultDesktopManager for now, as a) 
> this functionality has less priority for SwingNode (than JViewport) b) 
> it works fine in the default mode. So, I'll file a P5 against it.
>
> Please, look at the new webrev:
>
> http://cr.openjdk.java.net/~ant/JDK-8033233/webrev.1
>
> Besides modifications to DDM, I've put additional bounds constraint to 
> JLF/RepaintListener.repaintPerformed.
>
>> Also, could you please update the copyright years.
> Sure, I did.
>
>> Also, may be we could replace the RepaintListener instantiation in 
>> JLWF with a lambda? What do you think?
>
> Sure, we can.
>
> Thanks,
> Anton.
>
>>
>> With best regards. Petr.
>>
>> On 30.01.2014, at 17:49, "Anton V. 
>> Tarasov"<anton.tarasov at oracle.com>  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.
>