Sorry, I'm a bit sleepy today. The fix looks good to me. On 10.10.2013, at 15:39, Petr Pchelko <[email protected]> wrote:
> 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. >> >
