This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Change to coalescePaintEvents method's heuristics

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.)
> > 
> David,
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]