On 24.11.2016 16:44, Sergey Bylokhov wrote:
On 24.11.16 11:57, Semyon Sadetsky wrote:
On 23.11.2016 20:46, Sergey Bylokhov wrote:
On 14.11.16 12:03, Semyon Sadetsky wrote:
Please review the updated webrev:
http://cr.openjdk.java.net/~ssadetsky/8027639/webrev.01/
- buffer fill color is changed to 0,0,0,0
- graphics context background color and composition is restored
- scenario when the buffered JComponent has transparent background and
opaque=true is taken into account
I am not sure that the change in JComponent is necessary, because it
is responsibility of the component to return false from isOpaque() if
it has transparent background. Did you find what
components(lookAndFeels) breaks this contract?
Imagine you set a transparent background for the JRootPane but make it
opaque. Having this allowed for JComponents (unlike HW components) the
underling Window becomes visible but its surface is never cleared
without fixing the JComponent logic that stops repaint propagation at
the first opaque component without checking its background transparency.
So, to avoid artifacts one need either fix JComponent paint logic,
either disable for an opaque JComponent to have transparent background.
If someone(in the application) change the background to transparent
color then it should change opaque state as well.
Can you prove this statement at least with a reference to spec? It seems
JComponent does not imply this.
See how this is solved in HW window:
public boolean isOpaque() {
Color bg = getBackground();
return bg != null ? bg.getAlpha() == 255 : true;
}
In this way should work our UI delegates(which can change background
of the component and will change opaque state as well).
On 11/7/2016 7:01 PM, Sergey Bylokhov wrote:
On 07.11.16 18:31, Semyon Sadetsky wrote:
If it is src-over mean that in the window you will get a
composite of
colors, which was drawn to the backbuffer and the colors which was
drawn in the window(which was drawn by the window itself). And in
this
case you will get a different results when you paint via
backbuffer or
when you skip it.
I did not get this. You've state if JRootPane has own different
transparent color than it may be painted twice.
I am talking about the color of the window, you said that it is
always
painted.
http://mail.openjdk.java.net/pipermail/swing-dev/2016-October/006854.html
So if it always painted in case of non-opaque windows and you
paint it
to the backbuffer means that you paint it twice, no?
At first, I'm not sure that JRootPane may have such color.
Because we
only support window translucency if window is non-opaque and having
non-opaque window with opaque JRootPane seems incorrect usage.
The components can be opaque/non-opaque even if the window is
opaque/non-opaque. They have a different meaning. For window this
means that it has a transparent background, for components it means
that before the component is painted all its containers should be
painted first.
But anyway I don't see the way how the JRootPane transparent
color may
be pained twice. For non-opaque JRootPane it's background color
is not
painted, regardless of transparency. With opaque JRootPane the
parent
window paint() method will not be called and window background
will not
be painted.
Should the previous composite be restored after the rect
filling?
SRC should be the default composite type.
default composite type should be srcOver, and it should be
restored
before call paintToOffscreen().
