<AWT Dev> [8] Request for review: JDK-8022512 JLightweightFrame: the content pane should be transparent

[Anton V. Tarasov]

On 11.09.2013 12:43, Anthony Petrov wrote:
> Sure, I'm fine if for now this is an experimental, turned-off by default feature.

That's fine.

>
> BTW, do we really have to make any changes in JDK for it? Couldn't app's or demo's code itself 
> call the setOpaque(false) on its content pane (from an addNotify() override, for example)?

Sure, and this is what I do in the demo. However, the Content Pane, as the JLF frame itself are 
"transparent" to a user. The user just adds his/her JComponent to SwingNode and he/she theoretically 
should not bother about how we display it. At the same time, getParent() returns just the content 
pane, not null.

So, we can tell the user either (1) feel free to retrieve the parent of your JComponent and go ahead 
with it or (2) use the experimental property to alter the transparency. In my opinion, we should 
discourage people from changing anything in the content pane or JLF on their own. That's my reasoning.

Thanks,
Anton

>
> -- 
> best regards,
> Anthony
>
> On 09/11/2013 11:19 AM, Anton V. Tarasov wrote:
>> On 11.09.2013 0:11, Anthony Petrov wrote:
>>>> I just thought there might be an interest in this functionality.
>>>
>>> Personally, I'd prefer to hold back with this feature then, until such
>>> an interest is explicitly expressed by developers.
>>>
>>> If we still decide to implement this now though, then I'd consider the
>>> option #2: setting the cut-out shape for the Swing content pane. We
>>> have a similar API already [1], although it's currently applicable to
>>> the HW/LW Mixing functionality only. We could either extend its
>>> specification and area of applicability, or introduce a new similar
>>> method.
>>>
>>> [1] com.sun.awt.AWTUtilities.setComponentMixingCutoutShape()
>>
>> Right, [1] is what I'd just looked at.
>>
>> Ok, I think this is a topic which can be discussed on the upcoming J1
>> Interop BOF.
>>
>> In both cases, whether we decide to support it completely or not to
>> support officially, I guess having it as an experimental feature (via
>> introducing a property), switched off by default, wouldn't make any
>> harm. Will it? Why I'm requesting this, is because I have a demo for J1
>> which would benefit (as a demo) from this a lot. Moreover, it would be a
>> good illustration to the discussion. (Currently, it hacks the
>> transparency).
>>
>> So, what do you think about the property?
>>
>> Thanks,
>> Anton.
>>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 09/10/2013 10:10 PM, Anton V. Tarasov wrote:
>>>> Hi Anthony,
>>>>
>>>> Thanks for your point.
>>>>
>>>> On 09.09.2013 17:26, Anthony Petrov wrote:
>>>>> Hi Anton,
>>>>>
>>>>> The fix looks good I suppose. However, are you sure we want to support
>>>>> transparent content in embedded components? I understand that it's
>>>>> cool and stuff, but do we have to? We don't support transparency for
>>>>> heavyweight embedded frames (e.g. applets), why would we want to
>>>>> support it for the JLF? How are you going to handle mouse events on
>>>>> transparent parts? Will JFXPanel support the same?
>>>>
>>>> You're right, mouse events will anyway be caught by SwingNode on the
>>>> transparent area. What would we do with that? I'm just thinking of the
>>>> following:
>>>>
>>>> 1. Leave the Content Pane opaque.
>>>>
>>>> 2. Theoretically. Request a user to set a cutoff shape on the
>>>> lightweight content, convert it then to a clip shape for SwingNode.
>>>>
>>>> 3. Document the restrictions concerning mouse events, and provide a
>>>> property which would switch off the content pane's opacity.
>>>>
>>>> What do you think of the third approach? What if a node behind a
>>>> semi-transparent SwingNode doesn't have any interactivity in mind, and
>>>> simply is a one way display? I just thought there might be an interest
>>>> in this functionality. So, providing a documented or even undocumented
>>>> property could be useful.
>>>>
>>>> With regards to JFXPanel, as I can see it's the scene which stops
>>>> transparency of the whole hierarchy (JFXPanel itself allows zero
>>>> opacity). Allowing it to be transparent would make the case symmetrical.
>>>> Wouldn't it?
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>> On 09/03/2013 03:01 PM, Anton V. Tarasov wrote:
>>>>>> Please, review a fix.
>>>>>>
>>>>>> jira: https://bugs.openjdk.java.net/browse/JDK-8022512
>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8022512/webrev.0/
>>>>>>
>>>>>> Both JLF and its Content Pane are "transparent" to the client app,
>>>>>> e.g.
>>>>>> SwingNode, in terms of functionality. They should be physically
>>>>>> transparent as well, in order to support translucent Swing content.
>>>>>> This
>>>>>> is the case for JLF, but not for the Content Pane yet.
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>
>>