[8] Request for review: 7198229 [macosx] Painting during resizing of the frame should be more smooth
Anthony Petrov
anthony.petrov at oracle.com
Tue Oct 23 05:34:51 PDT 2012
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
>>>
>
>
More information about the macosx-port-dev
mailing list