Great, thank you, Anton. The fix looks good to me.
With best regards. Petr. 31 янв. 2014 г., в 11:55 до полудня, Anton V. Tarasov <[email protected]> написал(а): > 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. >
