<Swing Dev> <AWT Dev> [8] Review Request: JDK-8027157 [SwingNode] needs explicit expose for JWindow

[Anthony Petrov]

On 10/24/2013 11:06 AM, Anton V. Tarasov wrote:
> On 10/23/13 8:37 PM, Anthony Petrov wrote:
>> Not sure if this matters much, but normally we don't use *.swing.*
>> classes directly from *.awt.* classes to avoid inter-dependencies. It
>> would look better if you could use an approach based on the
>> Class.getName()/Class.getSuperClass() methods here.
> Right, I missed that. Thanks.

Looking forward to seeing a new webrev.


>> Also, I don't quite understand why "in case of interop WM_PAINT is
>> never triggered". W/o understanding this, I'm not sure if the current
>> fix is correct. Please elaborate on the root cause of the bug.
>
> Well, I agree we should understand why WM_PAINT is not generated.
> However, I'm afraid the investigation may take too much time and with no
> guarantee (that it can't be solved). This is a simple and, imo, harmless
> workaround which gets the issue solved in jfx8/jdk8. What about leaving
> the WM_PAINT issue open, but targeting it to the next release (when we
> have more time to investigate)?

Yes, I think this is a good option for now.

--
best regards,
Anthony

>
> Thanks,
> Anton.
>
>
>>
>> --
>> best regards,
>> Anthony
>>
>> On 10/23/2013 10:15 PM, Anton V. Tarasov wrote:
>>> Hello,
>>>
>>> Please, review the fix:
>>>
>>> jira: https://bugs.openjdk.java.net/browse/JDK-8027157
>>> webrev: http://cr.openjdk.java.net/~ant/RT-32570/webrev.0
>>>
>>> This is to support SwingNode. On Windows, in the interop mode, when a
>>> popup (JWindow) is shown it doesn't get WM_PAINT native message.
>>> The message should trigger adding a dirty component to RepaintManager
>>> that will eventually paint it.
>>> Currently, a popup is shown blank. Please, see
>>> https://javafx-jira.kenai.com/browse/RT-32570 for more details.
>>>
>>> The fix explicitly calls for WWindowPeer.handleExpose(..) on showing a
>>> window owned by JLightweightFrame.
>>>
>>> Thanks,
>>> Anton.
>