JDK-8033233 : [JLightweightFrame] support default JViewport BLIT_SCROLL_MODE
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 8,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-01-30
  • Updated: 2014-07-29
  • Resolved: 2014-01-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u20Fixed 9 b06Fixed
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.

This JIRA issue is aimed at implementing a mechanism which would let the JViewport work in its default BLIT scroll mode, which has better performance characteristics comparing to the BACKINGSTORE mode.
update: http://cr.openjdk.java.net/~ant/JDK-8033233/webrev.1 It contains changes to 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.

webrev: http://cr.openjdk.java.net/~ant/JDK-8033233/webrev.0 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.