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