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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Nov 29 17:11:24 UTC 2016


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.


More information about the awt-dev mailing list