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"<[email protected]> 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.
