[8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth

[Sergey Bylokhov]

New version of the fix:
http://cr.openjdk.java.net/~serb/7198229/webrev.01/

23.10.2012 16:34, Anthony Petrov wrote:
> On 10/23/2012 4:32 PM, Sergey Bylokhov wrote:
>>> src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
>>>>  503                 public synchronized void run() {
>>>
>>> Why does this method have to be synchronized? Do you expect the 
>>> Runnable.run() to be called many times from different threads?
>> I get this pattern from CDropTargetContextPeer.flushEvents(). This 
>> code can be safely removed later.
>
> Unless there's a clear reason for this method to be synchronized, I 
> suggest to remove this keyword from the method signature.
>
>
>>> I'm not an expert in CA layers, but I think changing from a layer 
>>> backed view to a layer hosting view is a big change. What tests did 
>>> you run to verify there's no regressions with rendering?
>> At least awt jck/regression tests passed. But sure some regressions 
>> could be introduced.
>
> Thanks. The fix looks safe then.
>
> -- 
> best regards,
> Anthony
>
>>>
>>> -- 
>>> best regards,
>>> Anthony
>>>
>>> On 10/23/2012 3:41 PM, Sergey Bylokhov wrote:
>>>> Hi Everyone,
>>>> Please review the fix.
>>>> This is an attempt to make our resizing better. I try to eliminate 
>>>> all unnecessary repaint actions.
>>>> 1 "Layer backed view" was changed to "Layer hosting view" - 
>>>> unnecessary call from drawRect() was eliminated. Now we post Paint 
>>>> event in the resize callback when necessary.
>>>> 2 CALayer options were changed, so now it don't force setNeedsDisplay.
>>>> 3 canDrawInCGLContext() was added to CGLLayer.m to eliminate 
>>>> unnecessary call to drawInCGLContext() when our 2d texture is not 
>>>> ready.
>>>> 4 CPlatformWindow.deliverMoveResizeEvent() make an attempt to 
>>>> expose LWWindowPeer synchronously. (LWCToolkit.invokeAndWait is used)
>>>>
>>>> After the fix we call Layer.setNeedsDisplay only in the Java2D 
>>>> Queue Flusher threads. It means that we have no possibility to 
>>>> accelerate resizing even more from awt side.
>>>> I'll make addition research of this question in the following CR.
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129082
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001213
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198229
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/7198229/webrev.00
>>>>
>>
>>


-- 
Best regards, Sergey.