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

Anthony Petrov anthony.petrov at oracle.com
Wed Sep 11 01:43:45 PDT 2013

Sure, I'm fine if for now this is an experimental, turned-off by default 

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)?

best regards,

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.

More information about the awt-dev mailing list