[OpenJDK 2D-Dev] <AWT Dev>  Please review fix for 7175183: [macosx] Objective-C exception thrown when switching monitor configuration
alexander.zuev at oracle.com
Tue Sep 4 17:27:00 UTC 2012
On 9/4/12 21:05, Phil Race wrote:
> This is a shared code change. Did you test it on Windows ?
Not yet - i'm building Windows version of jdk8 with that fix right now
and will test it tomorrow
but i don't see how changing of the sequence of invalidation of
accelerated texture and getting
of the backup surface can negatively affect the execution. But i will
have to test it nevertheless.
> In fact, can you explain why this has not been seen on Windows
> in the many years now that we've had this code ? eg, did we
> recently introduce a regression, is this MacOS specific ?
I think the reason is the hardware configuration common for Mac and rarely
found in PC's. Here's the way to introduce this bug:
1. User has to run Java application with the jdk7 or jdk8 on the
2. Then user has to close notebook lid. MacOS will then enter sleep mode
3. Then user has to connect external display without opening the
notebook lid - notebook will
automatically wake up and the applications will reemerge on the
At this stage user may receive the exception (he may not receive it - of
three mac notebooks
i tried that approach i only got an exception on one). Looks like
problem is caused by the fact
that while notebook is working with the integrated display it is being
powered by the less
powerful of the two adapters (unless configured differently) but
integrated graphics adapter can not
be used with the external display so system has to switch to discrete.
I don't think there's any hardware around where i can attempt to
reproduce this behavior on Windows - on
MacBook Windows only works with the discrete graphics adapter.
With best regards,
> On 9/4/2012 9:18 AM, Alexander Zuev wrote:
>> please review my fix for CR 7175183: [macosx] Objective-C exception
>> thrown when switching monitor configuration
>> The NPE happens because of the getBackupSurface method call may
>> result in the resetting of the current accelerated surface to null.
>> The idea of the fix is to move the invalidation of the accelerated
>> surface before the getBackupSurface() call.
>> Bug description is:
>> Webrev can be found here:
>> With best regards,
More information about the 2d-dev