JDK-6304251 : OGL+XAWT: Items in the drop-down are offset after setting the Choice's font at run time
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2005-07-30
  • Updated: 2011-01-25
  • Resolved: 2005-11-03
Related Reports
Duplicate :  
JDK-6322593 - OGL + XAWT: FileDialog drop-down is not properly painted when navigating thro' sub dirs
Relates :  
JDK-6304250 - XAWT: Items in choice show a blue border on OpenGL + Solaris10 when background color is set
Relates :  
JDK-6315137 - OGL+XAWT: AWT Menubar is not repainted properly when frame is resized
Description
I am running an application on OpenGL pipeline on SolSparc10. This application shows a Frame having a Choice and a button. I am selecting an item from the drop-down. When I click the button adjacent to it, I am changing the font size to 30 from the default size. After this, When I click the choice, none of the items in the drop-down are shown properly and the drop-down is completely messed up. This is reproducible on XToolkit with Tiger-FCS as well as Mustang. This is not reproducible with the default pipeline. This is not reproducible with win32. 

With the default pipeline, all the items are displayed properly with the new font size. I reproduced it on a SunBlade-2500 - SolSparc10 machine having a XVR-600 frame buffer. 

Run the attached test with OpenGL flag on the above solaris system and select an item from the drop-down. Click the button. Click on choice again. If the drop-down is messed up, the bug is reproduced. I have attached the platform information also to this bug report.
This is reproducible even when resizing a choice component on OpenGL. Add a choice to a frame and resize the frame in such a way that the choice also gets resized. Now click on the choice and check the drop-down. You would notice that the contents of the drop-down are painted properly only within the old bounds and the resized portion of the choice will appear blank. Say when you select an item, the 'selection' will be painted only till the old bounds and not in the resized area. This is not seen in non-OpenGL mode and not seen with Motif.
Comments
EVALUATION I think the problem here is that after the change in font size, the ListHelper ("unfurledChoice") window associated with the XChoicePeer is enlarged to account for the larger font size. It appears that the underlying X11 Window component is resized to account for this change, but the SurfaceData for that ListHelper window is not invalidated and recreated after the resize. So when OGL renders into that newly resized list window, we have no way of knowing that the window has been resized, and therefore we do not update the OGL viewport accordingly. This means that OGL renders into an area the size of the original bounds of the list window, which explains why you only see the list items rendered in the lower left of the newly resized list window. To fix this, it is necessary for the ListHelper's SurfaceData to be invalidated and recreated as part of the process of resizing the window. Otherwise, we have no way of knowing that the bounds of the window have changed (the OGL pipeline is particularly affected because it must always take the current bounds of the destination window into account when rendering, so it is important that this information is up-to-date). Recreating the SurfaceData is a usual process that happens when top-level windows are resized (either from a programmatic or user-initiated resize operation), so I'm not sure why that's not happening in this case. Reassigning to the AWT team for further investigation.
15-08-2005
EVALUATION When the submitter says "completely messed up", I assume that to mean that the contents of the list are offset significantly (down and to the left) of where they are supposed to be when the font size is changed. I am able to see this behavior on both Linux (with latest Nvidia drivers) and Solaris with the OGL pipeline enabled, so this problem is independent of the drivers or platform. And since this is only reproducible with XAWT (not with MAWT), there could be something about the way the choice popup window is created in XAWT that is interacting poorly with OGL. More investigation required. Also, it is interesting that with XAWT, the contents of the list have a red background, but with MAWT, the background is gray (only the borders of the list are red). I'm not sure if this is a bug, or perhaps an incompatible "feature" in XAWT.
15-08-2005
EVALUATION reproduced on Solaris 10 with JDK6.0b42
01-08-2005
EVALUATION An attempt to change font on Motif at runtime has no visible effect. Bug is reproducible on Linux with JDK6.0 and its definitely XAWT-specific. Motif behaviour should be considered as correct one. If XAWT Choice will not react on setFont call we probalby also fix described in Dscription section bug (if OpenGL-ed bug is not the same as seen on simple Linux). Should also note that on Win32 Choice changes its size after Frame being resized and this is the same as seen on simple Linux and described just above.
01-08-2005