<Swing Dev> [9] Review request for 8027639: JComboBox's popup leaves tracks after closing

[Sergey Bylokhov]

On 24.11.16 18:18, Semyon Sadetsky wrote:
>>>> 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;
>     }

The transparent windows were implemented much later than the code in 
JComponent this is why it was have alpha check. before that for a normal 
components it was responsibility of the users/ui delegates to support 
contact of JComponent.isOpaque.

>> 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().
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.