Hello, Leonid. > There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of > adding yet another bounds in LWWindowPeer? We are not adding yet another bounds in LWWindowPeer, we are removing them (sysX, sysY, sysW and sysH).
The bounds we are updating belong to LWComponentPeer, so we cannot remove them. We also cannot override getSize and getBounds in LWWindowPeer to return bounds from CPlatformWindow, because it's not an only implementation of the PlatformWindow. So this fix is the only option I see. With best regards. Petr. On 10.10.2013, at 15:27, Leonid Romanov <[email protected]> wrote: > There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of > adding yet another bounds in LWWindowPeer? > > On 10.10.2013, at 11:56, Petr Pchelko <[email protected]> wrote: > >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8024864 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8024864/webrev.00/ >> >> The problem: it's a hard-to-describe thread race. The main problem is the >> following: when we set the bounds of the frame they could be modified by the >> native system, so we reset them in notifyReshape. However, there are cases >> when the peer bounds, native bounds and frame bound get completely >> unsynchronized with each other. In those cases the rendering problems occur, >> because paint events are generated with wrong bounds. >> The solution is to only set peer's bounds in the callback from the native >> system and not set them in setBounds directly. This would fix the problem, >> because now the peer bounds and real native bounds are always synchronized >> and there's no time frame when the peers bounds are set to some different >> value which would then be updated by the native system. >> >> With best regards. Petr. >
