Quantcast

<AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

<AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Semyon Sadetsky
Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8170386

webrev: http://cr.openjdk.java.net/~ssadetsky/8170386/webrev.00/

Paint event may be missed by the JLightweightFrame on Windows platform
when it is resized consequently to the same size because the latter sets
paintPainding flag .

The fix overrides WComponentPeer#setBounds() method in
WLightweightFramePeer to clears paintPainding flag.

--Semyon



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Sergey Bylokhov
On 29.11.16 17:35, Semyon Sadetsky wrote:
> Paint event may be missed by the JLightweightFrame on Windows platform
> when it is resized consequently to the same size because the latter sets
> paintPainding flag .

 From what place the Paint will be posted after the call to setBounds()?
In case of normal native components this event will be posted from
native code after the size of the native component will be changed. But
how it works in case of JLightweightFrame? At least
COMPONENT_MOVED/COMPONENT_RESIZED are posted manually from the reshape()
method, probably we should do the same for the PAIN event as well? In
this case our optimization which coalesce PAINT events will work and the
sequence of setBounds() will produce only one repaint() action.

> The fix overrides WComponentPeer#setBounds() method in
> WLightweightFramePeer to clears paintPainding flag.

--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Semyon Sadetsky


On 11/29/2016 6:24 PM, Sergey Bylokhov wrote:

> On 29.11.16 17:35, Semyon Sadetsky wrote:
>> Paint event may be missed by the JLightweightFrame on Windows platform
>> when it is resized consequently to the same size because the latter sets
>> paintPainding flag .
>
> From what place the Paint will be posted after the call to
> setBounds()? In case of normal native components this event will be
> posted from native code after the size of the native component will be
> changed. But how it works in case of JLightweightFrame? At least
> COMPONENT_MOVED/COMPONENT_RESIZED are posted manually from the
> reshape() method, probably we should do the same for the PAIN event as
> well? In this case our optimization which coalesce PAINT events will
> work and the sequence of setBounds() will produce only one repaint()
> action.
Paint event is posted on resize and handled as usual in case of
JLightweightFrame, but the paint handler does not initiate the real
paint when paintPainding is true for optimization purpose because it
detects that the consequent paint event has been posted already.
>
>> The fix overrides WComponentPeer#setBounds() method in
>> WLightweightFramePeer to clears paintPainding flag.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Sergey Bylokhov
On 29.11.16 20:00, Semyon Sadetsky wrote:

>> From what place the Paint will be posted after the call to
>> setBounds()? In case of normal native components this event will be
>> posted from native code after the size of the native component will be
>> changed. But how it works in case of JLightweightFrame? At least
>> COMPONENT_MOVED/COMPONENT_RESIZED are posted manually from the
>> reshape() method, probably we should do the same for the PAIN event as
>> well? In this case our optimization which coalesce PAINT events will
>> work and the sequence of setBounds() will produce only one repaint()
>> action.
> Paint event is posted on resize and handled as usual in case of
> JLightweightFrame, but the paint handler does not initiate the real
> paint when paintPainding is true for optimization purpose because it
> detects that the consequent paint event has been posted already.

I doubt how it is possible. If the Paint event was posted from the
resize event it will reset the paintPainding to "false" in the
WComponentPeer.handleEvent():
         switch(id) {
             case PaintEvent.PAINT:
                 // Got native painting
                 paintPending = false;
                 // Fallthrough to next statement
             case PaintEvent.UPDATE:

But since the bug exists I assume that this message wasn't posted and
this is the reason why all other UPDATE events are skipped.

--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Semyon Sadetsky
On 11/29/2016 8:11 PM, Sergey Bylokhov wrote:

> On 29.11.16 20:00, Semyon Sadetsky wrote:
>>> From what place the Paint will be posted after the call to
>>> setBounds()? In case of normal native components this event will be
>>> posted from native code after the size of the native component will be
>>> changed. But how it works in case of JLightweightFrame? At least
>>> COMPONENT_MOVED/COMPONENT_RESIZED are posted manually from the
>>> reshape() method, probably we should do the same for the PAIN event as
>>> well? In this case our optimization which coalesce PAINT events will
>>> work and the sequence of setBounds() will produce only one repaint()
>>> action.
>> Paint event is posted on resize and handled as usual in case of
>> JLightweightFrame, but the paint handler does not initiate the real
>> paint when paintPainding is true for optimization purpose because it
>> detects that the consequent paint event has been posted already.
>
> I doubt how it is possible. If the Paint event was posted from the
> resize event it will reset the paintPainding to "false" in the
> WComponentPeer.handleEvent():
>         switch(id) {
>             case PaintEvent.PAINT:
>                 // Got native painting
>                 paintPending = false;
>                 // Fallthrough to next statement
>             case PaintEvent.UPDATE:
>
> But since the bug exists I assume that this message wasn't posted and
> this is the reason why all other UPDATE events are skipped.
Update is also a PaintEvent.
Another place that may be affected is endLayout() method which also
depends on the paintPending flag.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Sergey Bylokhov
On 29.11.16 20:55, Semyon Sadetsky wrote:

>> I doubt how it is possible. If the Paint event was posted from the
>> resize event it will reset the paintPainding to "false" in the
>> WComponentPeer.handleEvent():
>>         switch(id) {
>>             case PaintEvent.PAINT:
>>                 // Got native painting
>>                 paintPending = false;
>>                 // Fallthrough to next statement
>>             case PaintEvent.UPDATE:
>>
>> But since the bug exists I assume that this message wasn't posted and
>> this is the reason why all other UPDATE events are skipped.
> Update is also a PaintEvent.
> Another place that may be affected is endLayout() method which also
> depends on the paintPending flag.

Update is not a paint event, update is an event which posted as a result
of repaint(), but Paint event is an event which is results of the native
expose event(usually we have a postPaintEvent() method in peers). Since
the "paintPending" flag is not reset means that the Paint event is not
posted(seems that the reason is that we have no native part). And we
should do this from the WLightweightFramePeer in the same way as we post
COMPONENT_MOVED/COMPONENT_RESIZED

--
Best regards, Sergey.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Semyon Sadetsky
On 01.12.2016 03:18, Sergey Bylokhov wrote:

> On 29.11.16 20:55, Semyon Sadetsky wrote:
>>> I doubt how it is possible. If the Paint event was posted from the
>>> resize event it will reset the paintPainding to "false" in the
>>> WComponentPeer.handleEvent():
>>>         switch(id) {
>>>             case PaintEvent.PAINT:
>>>                 // Got native painting
>>>                 paintPending = false;
>>>                 // Fallthrough to next statement
>>>             case PaintEvent.UPDATE:
>>>
>>> But since the bug exists I assume that this message wasn't posted and
>>> this is the reason why all other UPDATE events are skipped.
>> Update is also a PaintEvent.
>> Another place that may be affected is endLayout() method which also
>> depends on the paintPending flag.
>
> Update is not a paint event,
There are two types of paint events in java: PaintEvent.PAINT and
PaintEvent.UPDATE.
> update is an event which posted as a result of repaint(), but Paint
> event is an event which is results of the native expose event
On windows platform it is called WM_PAINT message.
> (usually we have a postPaintEvent() method in peers). Since the
> "paintPending" flag is not reset means that the Paint event is not
> posted(seems that the reason is that we have no native part). And we
> should do this from the WLightweightFramePeer in the same way as we
> post COMPONENT_MOVED/COMPONENT_RESIZED
It is already posted on on the end of any layout. Why do you think the
extra paint event should be added to paint the same layout twice?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Sergey Bylokhov
(usually we have a postPaintEvent() method in peers). Since the "paintPending" flag is not reset means that the Paint event is not posted(seems that the reason is that we have no native part). And we should do this from the WLightweightFramePeer in the same way as we post COMPONENT_MOVED/COMPONENT_RESIZED
It is already posted on on the end of any layout. Why do you think the extra paint event should be added to paint the same layout twice?

If current code in idk does not work and we have a bug which we are discussing means that this event is not posted? If I missed something, then please clarify the problem.
Note, that if two event of the same type will be posted from a different places they will be merged(coalesced).
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Semyon Sadetsky

On 12/5/2016 5:48 AM, serb wrote:

(usually we have a postPaintEvent() method in peers). Since the "paintPending" flag is not reset means that the Paint event is not posted(seems that the reason is that we have no native part). And we should do this from the WLightweightFramePeer in the same way as we post COMPONENT_MOVED/COMPONENT_RESIZED
It is already posted on on the end of any layout. Why do you think the extra paint event should be added to paint the same layout twice?

If current code in idk does not work and we have a bug which we are discussing means that this event is not posted? If I missed something, then please clarify the problem.
> Paint event may be missed by the JLightweightFrame on Windows platform when it is resized consequently to the same size because the latter sets paintPainding flag .
"may" means it happens sometimes. It depends on the timings of the external resize notification.
Note, that if two event of the same type will be posted from a different places they will be merged(coalesced).
The coalescing is not issue because it joins repaint areas, so nothing will be missed.  The issue is that paint event may be completely ignored because of optimization which is not designed for other than native platform event scheduling.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: <AWT Dev> [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Sergey Bylokhov
Hello, Semyon.

On 12/5/2016 5:48 AM, serb wrote:

(usually we have a postPaintEvent() method in peers). Since the "paintPending" flag is not reset means that the Paint event is not posted(seems that the reason is that we have no native part). And we should do this from the WLightweightFramePeer in the same way as we post COMPONENT_MOVED/COMPONENT_RESIZED
It is already posted on on the end of any layout. Why do you think the extra paint event should be added to paint the same layout twice?

If current code in idk does not work and we have a bug which we are discussing means that this event is not posted? If I missed something, then please clarify the problem.
> Paint event may be missed by the JLightweightFrame on Windows platform when it is resized consequently to the same size because the latter sets paintPainding flag .
"may" means it happens sometimes. It depends on the timings of the external resize notification.

Can you please clarify why the bug is reproduced only if the WLFP is resized consequently to the same size? What is a sequence of calls which cause it? From the first point of view it looks strange because the paintPending flag will be set to false in the WWindowPeer.setBouns() if the size was not changed.
Loading...