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

Anton V. Tarasov anton.tarasov at oracle.com
Wed Sep 11 00:19:02 PDT 2013


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