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? Also, could you please update the copyright years. Also, may be we could replace the RepaintListener instantiation in JLWF with a lambda? What do you think? 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.
