<Swing Dev> Fake-Opaque Swing Components

[Shannon Hickey]

Hi Kirill,

Kirill Grouchnikov wrote:
> Shannon,
> 
> My intent was that the component will paint pixels that don't really 
> belong to it visually. While it will work for most of the application 
> that have grid-like layouts, it will result in incorrect clipping of 
> layout that use overlapping components. The same would apply for 
> animating the layout changes where controls would slide from place to 
> place - even if it happens for a fraction of second.

Completely agree. In fact, I'm personally not convinced of this 
proposal. I favor the correct use of isOpaque at this point.

> 
> And as far as i can tell from the rendering pipeline, a non-opaque 
> component does not cause the entire parent to be repainted - only the 
> relevant portion of the parent. While it still results in more repaints 
> (especially if the parent itself is non-opaque), it shouldn't be that 
> big of a problem.

I hope not. That's why I'm calling for concrete numbers.

Thanks,
Shannon

> 
> Thanks
> Kirill
> 
> 
> ----- Original Message ----
> From: Shannon Hickey <Shannon.Hickey at Sun.COM>
> To: Kirill Grouchnikov <kirillcool at yahoo.com>
> Cc: swing-dev at openjdk.java.net
> Sent: Monday, November 12, 2007 12:36:54 PM
> Subject: Re: <Swing Dev> Fake-Opaque Swing Components
> 
> Hi Kirill,
> 
> Kirill Grouchnikov wrote:
>  > Hi, Jasper
>  >
>  > Wouldn't that conflict with the optimizations made in the rendering
>  > pipeline? The component is still declared as opaque, but does not
>  > effectively paint all the pixels in its bounds.
> 
> Jasper's proposal WILL paint all pixels in its bounds. It simply
> mentions painting the outer edges in the parent background color.
> 
> 
>  > So, potentially you can
>  > have overlapping components (by design or during layout transitions)
>  > which will be cut off in that area around the visual painting of the
>  > components. In addition, this approach (as well as the existing one)
>  > doesn't address watermarking functionality.
>  >
>  > The issues with the performance can be addressed by repainting only the
>  > relevant area (such as caret does when it's blinking).
> 
> Of course. Swing already tries to constrain the areas that it repaints.
> What Jasper refers to is the performance hit we'll take (although it's
> not quantified how much...Jasper?) by forcing painting to start at a
> higher level.
> 
> Thanks!
> Shannon
> 
>  >
>  > Thanks
>  > Kirill
>  >
>  > ----- Original Message ----
>  > From: Jasper Potts <Jasper.Potts at Sun.COM <mailto:Jasper.Potts at Sun.COM>>
>  > To: swing-dev at openjdk.java.net <mailto:swing-dev at openjdk.java.net>
>  > Sent: Monday, November 12, 2007 10:53:41 AM
>  > Subject: <Swing Dev> Fake-Opaque Swing Components
>  >
>  > I have a problem with Nimbus that is common with other modern look and
>  > feels which we need to fix. The problem is how do setBackgound() and
>  > setForeground() map to how the component looks.
>  > Because of the some components having rounded corners and all components
>  > having 2px spacing for painting the focus glow. You end up with this
>  > background area around the component (in red above). The area is not
>  > really of color Component.getBackgound() as that has another meaning
>  > which is the background of the actual component content such as the text
>  > field background(in green above). 
>  >
>  > The obvious solution to the problem is to make the component non-opaque.
>  > Which means the red area would be transparent. The issue with this is it
>  > the performance for opaque components is much worse so for components
>  > like a text field which needs to be very responsive as you type this
>  > could be a issue.
>  >
>  > *P**roposed Solution*
>  > So the proposed solution is for the component to be opaque and the outer
>  > background area to be painted as before but be the parent components
>  > getBackgound() color. This seems the right answer but means a change at
>  > a low level. So what I propose is adding a UIManager property to turn
>  > this on and changing the ComponentUI.update() method from:
>  >
>  > public abstract class ComponentUI {
>  > ...
>  >  public void update(Graphics g, JComponent c) {
>  > if (c.isOpaque()) {
>  >    g.setColor(c.getBackground());
>  >    g.fillRect(0, 0, c.getWidth(),c.getHeight());
>  > }
>  > paint(g, c);
>  >  }
>  > ...
>  > }
>  >
>  > to:
>  >
>  > public abstract class ComponentUI {
>  > ...
>  >  public void update(Graphics g, JComponent c) {
>  > if (c.isOpaque()) {
>  >            if 
> (UIManager.getBoolean("Opaque.useParentBackgroundColor") &&
>  >                c.getParent() != null){
>  >                g.setColor(c.getParent().getBackground());
>  >            } else {
>  >            g.setColor(c.getBackground());
>  >            }
>  >    g.fillRect(0, 0, c.getWidth(),c.getHeight());
>  > }
>  > paint(g, c);
>  >  }
>  > ...
>  > }
>  >
>  > I am open for better suggestions for the UIManager key name but that is
>  > the basic idea.
>  >
>  > *So what do you think??????*
>  >
>  > Thanks
>  >
>  > Jasper
>  >
>  >
> 
> -- 
> Shannon Hickey
> shannon.hickey at sun.com <mailto:shannon.hickey at sun.com>
> Swing Team - Sun Microsystems, Inc.
> http://java.sun.com/javase/technologies/desktop
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

-- 
Shannon Hickey
shannon.hickey at sun.com
Swing Team - Sun Microsystems, Inc.
http://java.sun.com/javase/technologies/desktop