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

Semyon Sadetsky semyon.sadetsky at oracle.com
Thu Nov 24 16:59:19 UTC 2016



On 24.11.2016 18:52, Sergey Bylokhov wrote:
> 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 
That is good historical explanation why this happens, but it seem that 
it is a usual bug.
> to support contact of JComponent.isOpaque.
Still did not find this contract in JComponent.isOpaque spec.
>
>>> 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().
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>




More information about the swing-dev mailing list