<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.