JDK-4419252 : Expose events being incorrectly generated
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_7,solaris_8,solaris_9
  • CPU: generic,sparc
  • Submitted: 2001-02-27
  • Updated: 2001-07-31
  • Resolved: 2001-07-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.
Other
1.4.0 beta2Fixed
Related Reports
Duplicate :  
JDK-4469695 - Repaint causes windows to "flash" (worked in JDK1.3)
Duplicate :  
JDK-4468872 - JFrame with PLAF decorations blinks when JMenuBar is accessed
Duplicate :  
JDK-4394873 - Screen flash during Swing InternalFrame display (regression)
Duplicate :  
JDK-4459994 - painting regressions: wrong color and flashing
Duplicate :  
JDK-4464897 - the menu is twinkling
Duplicate :  
JDK-4455101 - Menu repaint problems on solaris.
Duplicate :  
JDK-4467126 - hiding popupmenu results in its invoker flash
Relates :  
JDK-4295524 - Swing popup menus cause Canvas3D to flash
Relates :  
JDK-4475369 - Using heavyweight over lightweight components we see unacceptable flashing
Description
The following has been reporoducable on Merlin for quite a while now. I tested with build 53 here. To reproduce this run InternalFrameDemo (part of SwingSet2, java -cp SwingSet2.jar InternalFrameDemo) then:

click on the minimize button of Frame 0
click on the minimized icon to restore it

Notice that the whole Frame appears to repaint.

I tracked this down some, and it would appear that when you click on the minimized icon MComponentPeer.handleExpose is invoked for the JFrame. This results in causing the whole frame to repaint.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004
EVALUATION Commit to fix in Merlin (performance). eric.hawkes@eng 2001-03-02 Committing to beta because Client decorated frames don't work acceptably well with this bug. eric.hawkes@eng 2001-03-11 Name: ssR10077 Date: 04/12/2001 It is a focus problem. The process of iconifying of JInternalFrame consists of Container.remove of JInternalFrame and Container.add of JInternalFrame.JDesktopIcon. Container.remove invokes Component.removeNotify() which calls KeyboardFocusManager.clearGlobalFocusOwner. After addition of JInternalFrame.JDesktopIcon the focus is transfered to it. Since focus is not inside of heavyweight parent of JInternalFrame.JDesktopIcon the MComponentPeer.requestFocus is called. It calls void setTreeTraversal(Widget w, Boolean trav) which causes repaint. The problem is very similar to 4295524. ====================================================================== Name: dkR10074 Date: 07/11/2001 ###@###.### 2001-07-11 First, the bug is the same as 4295524 which was closed as "will not fix". We have the following situation. Calling the native method KeyboardFocusManager.clearGlobalFocusOwner we want to redirect focus to the focus proxy of the active Window. The effect we want is for the active Window to remain active, but for none of its children to be the focus owner. AWT maintains a state to know that any key events delivered after this call (but before focus is re-established elsewhere) get ignored. Before requesting the focus by calling XmProcessTraversal(proxy, XmTRAVERSE_CURRENT) we have to temporarily turn off traversal on proxy's children. We do it calling setTreeTraversal(proxy, FALSE) which sets the resource XmNtraversalOn to FALSE for each child by XtVaSetValues. According to Xt's documentation in some cases XtVaSetValues causes the widget's expose procedure to be invoked by calling XClearArea() on the widget's window and the widget flashes. It happens if the widget (or at least one of widget's parent in hierarchy) has some constraints which have to be updated according to changed resources. I have found only the way to prevent calling parents' set_values methods. That is to change widget's parent to NULL before calling XtVaSetValues and restore the parent after that. In this case XtVaSetValues sets the resources of the widget without checking parent's constraint resources. Suggested fix fixes both 4295524 and 4419252. ====================================================================== Suggested fix causes Java to crash when you randomly click by mouse into different components. I modified it to set value of traversalOn property manually instead of by call to XtVaSetValues. ###@###.### 2001-07-18
18-07-2001
SUGGESTED FIX ------- awt_Component.c ------- *** /tmp/dHEaGAr Wed Jul 18 12:21:24 2001 --- awt_Component.c Wed Jul 18 12:18:46 2001 *************** *** 35,40 **** --- 35,42 ---- #include "jni_util.h" #include <jawt.h> #include <X11/extensions/Xdbe.h> + #include <Xm/PrimitiveP.h> + #include <Xm/ManagerP.h> /* CanvasType widgets: Frame, Dialog, Window, Panel, Canvas, * & all lightweights (Component, Container) *************** *** 269,274 **** --- 271,293 ---- XtVaSetValues(w, XmNforeground, fg, NULL); } + // Sets widget's traversalOn property into value 'value' + void setTraversal(Widget w, Boolean value) { + if (w == NULL) { + return; + } + if (XmIsPrimitive(w)) { + XmPrimitiveWidget prim = (XmPrimitiveWidget)w; + prim->primitive.traversal_on = value; + return; + } + if (XmIsManager(w)) { + XmManagerWidget man = (XmManagerWidget)w; + man->manager.traversal_on = value; + return; + } + } + void setTreeTraversal(Widget w, Boolean trav) { *************** *** 275,280 **** --- 294,300 ---- WidgetList children; int32_t numChildren; int32_t i; + Widget parent; XtVaGetValues(w, XmNchildren, &children, *************** *** 283,289 **** for (i = 0; i < numChildren; i++) { if (!XtIsSubclass(children[i], xmScrollBarWidgetClass)) { ! XtVaSetValues(children[i], XmNtraversalOn, trav, NULL); } if (IsCanvasTypeWidget(children[i])) { setTreeTraversal(children[i], trav); --- 303,326 ---- for (i = 0; i < numChildren; i++) { if (!XtIsSubclass(children[i], xmScrollBarWidgetClass)) { ! /* ! * Fix for 4419252 by ###@###.### ! * We call this function from requestFocus and clearGlobalFocusOwner ! * to turn off/on traversal on w's children. The calls to this ! * function envelop the call of XmProcessTraversal. Due to switching ! * of child's resource XmNtraversalOn to FALSE the widget flashes. ! * It happens because we want some strange things from Xt's point of ! * view when, for instance, we try to set the focus to a container ! * (like proxy). Thus, I think there is no good fix but only a hack ! * like we can see below. ! * The following code does not look too risky at the moment but, ! * probably, it might become such in the future. ! */ ! if (trav) { ! XtVaSetValues(children[i], XmNtraversalOn, trav, NULL); ! } else { ! setTraversal(children[i], trav); ! } } if (IsCanvasTypeWidget(children[i])) { setTreeTraversal(children[i], trav); ###@###.### 2001-07-18
18-07-2001