<Swing Dev> [9] Review request for 8027639: JComboBox's popup leaves tracks after closing
Semyon Sadetsky
semyon.sadetsky at oracle.com
Thu Nov 24 15:18:16 UTC 2016
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().
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
More information about the swing-dev
mailing list