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

[Alexander Scherbatiy]

  Do not worry. The fix looks good for me.

  Thanks,
  Alexandr.

On 1/31/2014 3:12 PM, Anton V. Tarasov wrote:
> On 31.01.2014 14:08, Alexander Scherbatiy wrote:
>>
>>   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  {...} ".
>
> I just wanted to keep it close to the copyArea (I had to let 
> f.setBounds(currentBounds) go first). But I'm Ok to change it, I'll do 
> that with push, if you don't object.
>
> Thanks,
> Anton.
>
>>
>>   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.
>>>
>>
>