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.
