Graphics.hitClip returning false, children don't paint

Thu Jan 26 19:48:00 GMT 2006

I got the latest gcc sources yesterday, and tried some AWT examples using
xlib peers (although I don't think this is an xlib peer problem). Simple
programs work, but when a Container has a bunch of children, they don't all
paint. I have a clunky work-around, but I don't think it's reasonable, and
I'm hoping somebody can let me know whether it's being worked on and/or
where it ought to be fixed.
The attached test program is supposed to print a 3x5 grid of numbered
rectangles in various colours. With my old patched branch-4.0 gcc, it does.
With the latest code, only a few of the children paint. In the source code,
if you re-name "zzpaint" to "paint" (line #86), the thing works with the
latest code. That method duplicates what Container.paint does, with one
change (which I'm absolutely sure is NOT the right way to get it working -- 
it's just an experiment):
Changed:
 if(!g.hitClip (bounds.x,bounds.y, bounds.width, bounds.height))
to:
 if(!g.hitClip (bounds.x+g.getClipBounds ().x,bounds.y+g.getClipBounds
().y, bounds.width, bounds.height))
There's a translation in the parent's x,y (in IntegerGraphicsState)
affecting the returned Rectangle from getClipBounds. Since hitClip uses the
shifted clip rectangle, and the childrens' bounds are not shifted, it
sometimes returns false when it shouldn't.
Where my knowledge lets me down is in deciding what's supposed to be
relative to what. When I run my program in the Sun JRE, with the overridden
paint but without the modified hitClip call (i.e. emulating what classpath's
Container.paint does, but printing stuff out), everything works and the clip
bounds always has zero x & y values. With yesterday's gcc, the same code
shows the x & y from the clip bounds changing each time "g2" is created with
Graphics.create(x,y,w,h). It seems to me that our clip bounds ought to act
the same way as Sun's. Maybe that means IntegerGraphicsState.getClip and
IntegerGraphicsState.getClipBounds shouldn't do clipRect.x -= tx and
clipRect.y -= ty, or maybe there's an extra translation somewhere.
Does anybody have some insight into how the clip regions are supposed to
work and/or whether there's an obvious fix?
As I say, I'm pretty sure this is not an xlib peer problem, because the
methods I looked at are all outside the xlib peers. I'm open to being
proven wrong on that, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GridLayoutTest.java
Type: application/octet-stream
Size: 5860 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060126/92d857e6/attachment.obj>