Sure, I'm fine if for now this is an experimental, turned-off by default
feature.
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,
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.
