This is the mail archive of the
mailing list for the Java project.
Re: [PATCH] Change to coalescePaintEvents method's heuristics
- From: Thomas Fitzsimmons <fitzsim at redhat dot com>
- To: Fernando Nasser <fnasser at redhat dot com>
- Cc: David Jee <djee at redhat dot com>, libgcj patches <java-patches at gcc dot gnu dot org>
- Date: Mon, 19 Jan 2004 18:08:04 -0500
- Subject: Re: [PATCH] Change to coalescePaintEvents method's heuristics
- References: <email@example.com> <400C2D35.firstname.lastname@example.org>
On Mon, 2004-01-19 at 14:17, Fernando Nasser wrote:
> David Jee wrote:
> > We could introduce a mechanism to explicitly and forcefully repaint the
> > erased heavyweight components, but that seems like a hack to me. (I
> > could be wrong on this. Comments are welcome.)
> What if a heavyweight component is already over one of the areas to be repainted
> (forget the coalescing for a moment)? We will have to repaint those anyway, right?
> In general, we must repaint all heavyweight components that fall in any of the
> areas to be repainted as their Z-order is always higher than the Z-order of the
> lightweight ones.
Though this is how proprietary JVMs implement things, I don't think we
*have* to follow suit. This behaviour is not really specified, and most
books recommend against mixing heavy and lightweight components. I
can't imagine many applications relying on heavyweight components always
being on top.
This behaviour seems more like a limitation of existing AWT
implementations than a design decision. So if we can handle collating
heavyweight and lightweight components in the same z order stack with
little extra implementation effort, then I don't see any reason not to.
That said, I have no idea how much extra effort would be required to
handle this properly -- I'm just saying that we shouldn't match the
limitations of other implementations where we can do a better
implementation and still match the specs.