|
Replies:
2
-
Last Post:
Apr 25, 2008 9:38 AM
by: kirillcool
|
|
|
|
|
|
|
Nimbus and JXPanel.setAlpha
Posted:
Apr 25, 2008 12:21 AM
|
|
|
Testing Nimbus on the SwingX components, i tried playing with JXPanel.setAlpha and there are quite a few visual artifacts (that interestingly enough uncover some of the inner visuals - just place an empty JDesktopPane in a JXPanel with alpha 0.5 and you'll see how the gradients are painted).
The code in JXPanel.paint is this:
public void paint(Graphics g) {
Graphics2D g2d = (Graphics2D)g;
Composite oldComp = g2d.getComposite();
float alpha = getEffectiveAlpha();
Composite alphaComp = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, alpha);
g2d.setComposite(alphaComp);
super.paint(g2d);
g2d.setComposite(oldComp);
}
However, when custom UI delegate gets this graphics and installs its own alpha composite (as Nimbus is clearly doing), the JXPanel-derived one is gone. I had to go through a lot of trouble in Substance to respect the original alpha, and it might be hurting its performance.
So, the main question would be - is Nimbus planned to play well with SwingX in general and with JXPanel in particular? If the answer is yes and yes, i would be interested to hear Richard's thoughts on the subject of performance and code complexity due to the current implementation of JXPanel.paint.
Kirill
|
|
|
|
|
|
|
Re: Nimbus and JXPanel.setAlpha
Posted:
Apr 25, 2008 9:21 AM
in response to: kirillcool
|
|
|
Hi Kirill,
I need to look into this. FWIW, JXPanel is doing evil things with alpha that needs to be fixed. Setting the alpha composite often leads to surprising errors depending on how the components are nested. The right solution is to render into a buffered image and draw that to the graphics with alpha applied. I'd be interested in seeing how this interplays. In particular, with a patched version of SwingX's JXPanel Amy got it all working correctly in SwingSet3.
I'll need to look at it in more detail.
Thanks
Richard
|
|
|
|
|
|
|
|
|
Re: Nimbus and JXPanel.setAlpha
Posted:
Apr 25, 2008 9:38 AM
in response to: rbair
|
|
|
Hi, Richard
I agree that the current implementation of JXPanel.update and JXPanel.getEffectiveAlpha are far from optimal. In my opinion, having nested JXPanel with different alphas should multiply the respective alphas and not take the lower one. In addition, as you note, the rendering should be done to an offscreen image and then painted back.
What are your thoughts in general on the assumptions that UI delegates can make on the Graphics object passed to the update / paint methods? Can we always assume that there is no AlphaComposite installed there? If so, the code can be much simpler (and faster, one would presume).
Thanks
Kirill
|
|
|
|
|
java.net RSS
