Re: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing

[Jim Graham]

Hi Oleg,

Let me clarify, I'm not referring to a "better way" to fix this. 
Actually, the fix you have prepared has a problem.  Once the SD is 
"invalid due to switching to software" and the SG2D decides to install a 
null SD instead, then it will never recover.  But, no change to a 
drawable should happen (other than it going away) to cause that state. 
The SG2D's were designed to survive changes in state to the underlying 
drawable, as long as it remains viable as a drawing destination, but 
here you are giving up on it when that (externally not really very 
obvious) state change occurs.  Thread A could be happily rendering to 
the surface on the screen, thread B decides to use XOR thereby changing 
the state, but thread A's G2D now stops working?  Thread A would be very 
very confused.


So, while there may be a fix we could add to SG2D to work around the 
problem, your fix isn't the right solution.  I believe that the right 
solution is to have the D3DSurface return the correct new surface, but 
it being "what I think is the right solution" is just part of the issue 
with your currently proposed fix - the proposed fix violates a 
long-standing behavior of G2D objects to remain viable until the surface 
is gone...


...jim

On 8/24/2012 3:01 AM, Oleg Pekhovskiy wrote:

Hi Jim,

first of all I should say, that I prepared that fix for 7u as the most
safe, with minimum changes.
I agree that getReplacement() should return a valid sufrace or null, but
it doesn't happen during that switch.

That CR was assigned to me because my previous changes for:
7112642 Incorrect checking for graphics rendering object
7121482 some sun/java2d and sun/awt tests failed with InvalidPipeException
discovered the problem with getReplacement() and were somehow related.

But maybe it would be better to create a separate CR for
getReplacement() issue and assign it to Java2d Team?
I also could add a comment for "!surfaceData.isValid()" reffering to
CR7153339.

What do you think?

Thanks,
Oleg

24.08.2012 4:04, Jim Graham wrote:

Hi Oleg,

getReplacement should not be returning an invalid surface. If the
current D3DSD is invalid, then it should return a valid replacement.
The only time it should return null is when the window is gone. It
sounds like the window isn't gone here, it has just switched over to a
non-D3D type of SurfaceData and return that...

...jim

On 8/23/2012 4:37 PM, Oleg Pekhovskiy wrote:

Hi Phil, Jim,

thank you for pointing out the testing work that should be performed.
I tested my fix with the following regression tests:
test/java/awt/Graphics
test/java/awt/Graphics2D
test/java/awt/GraphicsDevice
test/java/awt/GraphicsEnvironment
test/sun/java2d

Plus I tested performance differences on:
demo/jfc/Java2D/Java2Demo.jar

Testing was done on Windows 7 & Ubuntu 12.04 LTS.
No differences were found.

I also asked Yuri Nesterenko to test all that stuff on Mac.

Thanks,
Oleg


11.08.2012 3:10, Phil Race wrote:

Oleg,
This looks OK to me but since this is a shared code change I have
to ask what testing you've done ?

Also why not provide a regression test ? The provided test was
interactive but I think it can be automated.

You need another review and I'd like Jim to take a look.

-phil.

On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote:

Hi,

Please review the fix for CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339

Webrev:
http://cr.openjdk.java.net/~bagiras/8/7153339.1/

Comments:
XOR is not supported for D3D (see comments inside
D3DSurfaceData.validatePipe()) and
software rendering is used invalidating current D3DSurfaceData.
So we have situation when component's peer has invalid SurfaceData
and it's retrieved in
SunGraphics2D.revalidateAll() through SurfaceData.getReplacement()
without any check.
That's why I added validity check there.

Thanks,
Oleg

Re: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

[Sergey Bylokhov]

Hi Alexander.
In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did 
not see  cursorUpdate: method. Probably we can get some useful 
information from it?


24.08.2012 17:53, Alexander Scherbatiy пишет:


Could you review the updated fix:
  http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/
The comments are below:

On 8/23/2012 4:51 PM, Anthony Petrov wrote:

Hi Alexandr,

1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate 
through app's windows only once and send both Exited and Entered 
events where needed?
Now, when we do not care about the order of the mouse enter/exit 
events generation it is possible to do. I have updated the code.


2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no 
longer requires a window pointer as an argument.

   Fixed.


3. Here's a major concern: the LWWindowPeer (and other LW* classes) 
should never import C* classes. Instead you should've added a new 
method to the PlatformWindow interface, and used it from 
LWWindowPeer. The CPlatformWindow should've implemented this method, 
and called an appropriate native method from there. In this case, 
however, you actually need a static method, so it'd better be part of 
the LWToolkit interface, and implemented in the LWCToolkit class 
instead.
 I see.  It seems that the getTopmostWindowUnderMouse method 
implementation is different for the CPlatformWindow and for the 
CPlatformEmbeddedFrame.
 So I added the getTopmostPlatformWindowUnderMouse method to the 
PlatformWindow  interface.


Thanks,
Alexandr.



--
best regards,
Anthony

On 08/23/12 15:40, Alexander Scherbatiy wrote:


Could someone review the fix?

Thanks,
Alexandr.

On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote:


Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/

The comments are below:

On 8/7/2012 6:47 PM, Mike Swingler wrote:

I noticed that, NSWindow's windowNumber is NSInteger, which is 32
bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a
simple 32 bit int is probably not what you intended to do.

fixed.

Also, have you considered simply calling -[NSWindow
setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then
removing the calls that flip it on and off in -[AWTView
mouseEntered:] and -[AWTView mouseExited"]? This would also require a
change in
Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(),
which has a comment that states it only turns on mouse moved events
if the window is currently under the mouse.

I tried it. The result that I got is that a dragging mouse from one
window to another does not generate mouse enter/exit events on the
second window in case when tracking rect is used and the
acceptsMouseMovedEvents flag is always set to YES.


I would think that AppKit should be more than happy to send you
mouse-over/enter/exited events as long as you say you want them. Was
this approach tried and didn't work for some reason?

Hi, Alexander.
Probably all this stuff can be simplified? Can you try to change
TrackingRect to TrackingArea with appropriate flags like
NSTrackingEnabledDuringMouseDrag etc.

I changed the TrackingRect to TrackingArea in the updated fix. It now
generates the mouse enter/exit events on the second window during 
drag.

So it is not necessary to generates such events from our side.

The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit
events for component in case when a mouse is dragged from one window
to another.
Where the second window contains it's own components and the only way
to know about tracking over them are drag events which receives the
first window.

I think that the LWWindowPeer class code can be simplified if we
assume that window mouse enter/exit events are always come to the
current window.
So the component mouse enter/exit events can be tracked only in the
current or topmost window.
For this case I separated the global lastCommonMouseEventPeer which is
necessary for the cursor manager and the local lastMouseEventPeer.

According to the specification: The proper order of mouse-entered and
mouse-exited events received by tracking-area objects in an
application cannot be guaranteed.
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html 



So it seems it is not possible to have one lastMouseEventPeer instead
of two: lastCommonMouseEventPeer and lastMouseEventPeer.

And there are possible situations that we can receive mouse drag event
between enter and exit.
To handle this the isMouseOver flag is added to the LWWindowPeer
class. So the component mouse enter/exit events are not generated if
the window mouse exited event is received and window mouse entered is
not.

There is the test:
test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java
It shows that even using the TrackingArea some mouse enter/exit events
are not generateed in the following cases:
- window is crea

[7u8] Review request for 7193219: JComboBox serialization fails in JDK 1.7

[Anton Litvinov]

Hello,

Please review the following fix for a bug.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7193219
Webrev: http://cr.openjdk.java.net/~alexp/7193219/webrev.00

For details on this bug please look at "Evaluation" field on a web page 
of this bug. The provided webrev contains both a fix and a corresponding 
unit-test. Also before publishing this webrev all unit-test from the 
"java.awt" and
"javax.swing" swing related to serialization and usage of 
"GraphicsConfiguration" class were run and no negative changes were 
observed comparing the results of tests' runs on JDK with and without 
patch represented by this webrev.


Thank you,
Anton

Re: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

[Anthony Petrov]

Hi Alexandr,

src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java

 66 public static native CPlatformWindow 
nativeGetTopmostPlatformWindowUnderMouse();


This method must probably be private.

Still, I don't see why getTopmostPlatformWindowUnderMouse() must return 
null when it's invoked on an embedded frame, and why the implementation 
should even be different at all. The mouse is a global system entity. 
There's either some window under the mouse, or there's not. I would 
still think of LWToolkit.getPlatformWindowUnderMouse(), and its 
implementation in LWCToolkit.


Also, the logic in LWWindowPeer lines 722-743 seems to be overly 
complicated (as well as the whole dispatchMouseEvent() method). E.g., if 
the LWWindowPeer manages an embedded frame, we get topmostWindowPeer == 
this at line 730, and thus always go through the 'true' branch of if() 
at line 733, even though actually the mouse pointer can be located over 
some other window at the moment (e.g. over a popup window opened by an 
applet).


Overall, it's really difficult to understand what is going on there. 
I've spent half an hour reading the code and am still not sure if I get 
it right. Why does LWWindowPeer even care about the EXITED/ENTERED 
events for components? Shouldn't this code belong to LWComponentPeer? Or 
even the shared code? How do Swing components in regular Swing apps get 
the ENTERED/EXITED events then? Why can't we use the same approach for 
LWAWT?


--
best regards,
Anthony

On 8/24/2012 5:53 PM, Alexander Scherbatiy wrote:


Could you review the updated fix:
  http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/
The comments are below:

On 8/23/2012 4:51 PM, Anthony Petrov wrote:

Hi Alexandr,

1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate 
through app's windows only once and send both Exited and Entered 
events where needed?
Now, when we do not care about the order of the mouse enter/exit 
events generation it is possible to do. I have updated the code.


2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no 
longer requires a window pointer as an argument.

   Fixed.


3. Here's a major concern: the LWWindowPeer (and other LW* classes) 
should never import C* classes. Instead you should've added a new 
method to the PlatformWindow interface, and used it from LWWindowPeer. 
The CPlatformWindow should've implemented this method, and called an 
appropriate native method from there. In this case, however, you 
actually need a static method, so it'd better be part of the LWToolkit 
interface, and implemented in the LWCToolkit class instead.
 I see.  It seems that the getTopmostWindowUnderMouse method 
implementation is different for the CPlatformWindow and for the 
CPlatformEmbeddedFrame.
 So I added the getTopmostPlatformWindowUnderMouse method to the 
PlatformWindow  interface.


Thanks,
Alexandr.



--
best regards,
Anthony

On 08/23/12 15:40, Alexander Scherbatiy wrote:


Could someone review the fix?

Thanks,
Alexandr.

On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote:


Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/

The comments are below:

On 8/7/2012 6:47 PM, Mike Swingler wrote:

I noticed that, NSWindow's windowNumber is NSInteger, which is 32
bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a
simple 32 bit int is probably not what you intended to do.

fixed.

Also, have you considered simply calling -[NSWindow
setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then
removing the calls that flip it on and off in -[AWTView
mouseEntered:] and -[AWTView mouseExited"]? This would also require a
change in
Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(),
which has a comment that states it only turns on mouse moved events
if the window is currently under the mouse.

I tried it. The result that I got is that a dragging mouse from one
window to another does not generate mouse enter/exit events on the
second window in case when tracking rect is used and the
acceptsMouseMovedEvents flag is always set to YES.


I would think that AppKit should be more than happy to send you
mouse-over/enter/exited events as long as you say you want them. Was
this approach tried and didn't work for some reason?

Hi, Alexander.
Probably all this stuff can be simplified? Can you try to change
TrackingRect to TrackingArea with appropriate flags like
NSTrackingEnabledDuringMouseDrag etc.

I changed the TrackingRect to TrackingArea in the updated fix. It now
generates the mouse enter/exit events on the second window during drag.
So it is not necessary to generates such events from our side.

The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit
events for component in case when a mouse is dragged from one window
to another.
Where the second window contains it's own components and the only way
to know about tracking over them are drag events which receives the
first window.

Re: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing

[Oleg Pekhovskiy]

Hi Phil,

I forgot to mention the test creation problem.

The manual test proposed in CR's description just
relies on specific call sequence after getReplacement() returns invalid 
surfaceData.


So the test doesn't catch InvalidPipeException when invalid surfaceData 
found,

because this exception is cought in sun.java2d.SunGraphics2D.drawLine().

But it just catches java.lang.InternalError that is thrown on catch of 
Throwable exception

(indeed InvalidPipeException) that is thrown from:
sun.java2d.SunGraphics2D.validatePipe(SunGraphics2D.java:380)
with the stack:
sun.java2d.SunGraphics2D.revalidateAll(SunGraphics2D.java:2363)
sun.java2d.SunGraphics2D.getCompClip(SunGraphics2D.java:496)
sun.java2d.pipe.LoopPipe.getStrokeSpans(LoopPipe.java:270)
sun.java2d.pipe.LoopPipe.draw(LoopPipe.java:201)
sun.java2d.pipe.PixelToShapeConverter.drawLine(PixelToShapeConverter.java:52)
sun.java2d.pipe.ValidatePipe.drawLine(ValidatePipe.java:62)
sun.java2d.SunGraphics2D.drawLine(SunGraphics2D.java:2137)

Could we rely on such indirect error in our case?
As I remember you had plans to refactor Graphics related stuff, so the 
sequence could change

making test's expectations odd.

Thanks,
Oleg

24.08.2012 3:37, Oleg Pekhovskiy wrote:

Hi Phil, Jim,

thank you for pointing out the testing work that should be performed.
I tested my fix with the following regression tests:
test/java/awt/Graphics
test/java/awt/Graphics2D
test/java/awt/GraphicsDevice
test/java/awt/GraphicsEnvironment
test/sun/java2d

Plus I tested performance differences on:
demo/jfc/Java2D/Java2Demo.jar

Testing was done on Windows 7 & Ubuntu 12.04 LTS.
No differences were found.

I also asked Yuri Nesterenko to test all that stuff on Mac.

Thanks,
Oleg


11.08.2012 3:10, Phil Race wrote:

Oleg,
This looks OK to me but since this is a shared code change I have
to ask what testing you've done ?

Also why not provide a regression test ? The provided test was
interactive but I think it can be automated.

You need another review and I'd like Jim to take a look.

-phil.

On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote:

Hi,

Please review the fix for CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339

Webrev:
http://cr.openjdk.java.net/~bagiras/8/7153339.1/

Comments:
XOR is not supported for D3D (see comments inside 
D3DSurfaceData.validatePipe()) and

software rendering is used invalidating current D3DSurfaceData.
So we have situation when component's peer has invalid SurfaceData 
and it's retrieved in
SunGraphics2D.revalidateAll() through SurfaceData.getReplacement() 
without any check.

That's why I added validity check there.

Thanks,
Oleg

Re: [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

[Alexander Scherbatiy]

Could you review the updated fix:
  http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/
The comments are below:

On 8/23/2012 4:51 PM, Anthony Petrov wrote:

Hi Alexandr,

1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate 
through app's windows only once and send both Exited and Entered 
events where needed?
Now, when we do not care about the order of the mouse enter/exit 
events generation it is possible to do. I have updated the code.


2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no 
longer requires a window pointer as an argument.

   Fixed.


3. Here's a major concern: the LWWindowPeer (and other LW* classes) 
should never import C* classes. Instead you should've added a new 
method to the PlatformWindow interface, and used it from LWWindowPeer. 
The CPlatformWindow should've implemented this method, and called an 
appropriate native method from there. In this case, however, you 
actually need a static method, so it'd better be part of the LWToolkit 
interface, and implemented in the LWCToolkit class instead.
 I see.  It seems that the getTopmostWindowUnderMouse method 
implementation is different for the CPlatformWindow and for the 
CPlatformEmbeddedFrame.
 So I added the getTopmostPlatformWindowUnderMouse method to the 
PlatformWindow  interface.


Thanks,
Alexandr.



--
best regards,
Anthony

On 08/23/12 15:40, Alexander Scherbatiy wrote:


Could someone review the fix?

Thanks,
Alexandr.

On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote:


Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/

The comments are below:

On 8/7/2012 6:47 PM, Mike Swingler wrote:

I noticed that, NSWindow's windowNumber is NSInteger, which is 32
bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a
simple 32 bit int is probably not what you intended to do.

fixed.

Also, have you considered simply calling -[NSWindow
setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then
removing the calls that flip it on and off in -[AWTView
mouseEntered:] and -[AWTView mouseExited"]? This would also require a
change in
Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(),
which has a comment that states it only turns on mouse moved events
if the window is currently under the mouse.

I tried it. The result that I got is that a dragging mouse from one
window to another does not generate mouse enter/exit events on the
second window in case when tracking rect is used and the
acceptsMouseMovedEvents flag is always set to YES.


I would think that AppKit should be more than happy to send you
mouse-over/enter/exited events as long as you say you want them. Was
this approach tried and didn't work for some reason?

Hi, Alexander.
Probably all this stuff can be simplified? Can you try to change
TrackingRect to TrackingArea with appropriate flags like
NSTrackingEnabledDuringMouseDrag etc.

I changed the TrackingRect to TrackingArea in the updated fix. It now
generates the mouse enter/exit events on the second window during drag.
So it is not necessary to generates such events from our side.

The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit
events for component in case when a mouse is dragged from one window
to another.
Where the second window contains it's own components and the only way
to know about tracking over them are drag events which receives the
first window.

I think that the LWWindowPeer class code can be simplified if we
assume that window mouse enter/exit events are always come to the
current window.
So the component mouse enter/exit events can be tracked only in the
current or topmost window.
For this case I separated the global lastCommonMouseEventPeer which is
necessary for the cursor manager and the local lastMouseEventPeer.

According to the specification: The proper order of mouse-entered and
mouse-exited events received by tracking-area objects in an
application cannot be guaranteed.
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html 



So it seems it is not possible to have one lastMouseEventPeer instead
of two: lastCommonMouseEventPeer and lastMouseEventPeer.

And there are possible situations that we can receive mouse drag event
between enter and exit.
To handle this the isMouseOver flag is added to the LWWindowPeer
class. So the component mouse enter/exit events are not generated if
the window mouse exited event is received and window mouse entered is
not.

There is the test:
test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java
It shows that even using the TrackingArea some mouse enter/exit events
are not generateed in the following cases:
- window is created under the mouse
- window changes it's bounds so it becomes under the mouse

For this cases it still necessary to generate mouse enter/exit events
from our side.
I just moved the related code to one method
synthesizeMou

hg: jdk8/awt/jdk: 7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] gldAttachDrawable+0x941)

[anthony . petrov]

Changeset: e3122759abe3
Author:anthony
Date:  2012-08-24 14:58 +0400
URL:   http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e3122759abe3

7160609: [macosx] JDK crash in libjvm.dylib ( C [GeForceGLDriver+0x675a] 
gldAttachDrawable+0x941)
Summary: Constrain window dimensions with screen bounds and GL_MAX_TEXTURE_SIZE
Reviewed-by: art, serb

! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/PlatformWindow.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m
+ src/share/classes/sun/awt/TextureSizeConstraining.java
+ test/java/awt/Frame/HugeFrame/HugeFrame.java

Re: [8] Review request for 7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo

[Anthony Petrov]

Looks fine.

--
best regards,
Anthony

On 8/24/2012 1:29 PM, Konstantin Shefov wrote:

Hello,

Please review a fix for the issue:

7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo

Test should be modified in jdk8 to be run via jtreg

The webrev is http://cr.openjdk.java.net/~kshefov/7184326/webrev.00/


Thanks,
Konstantin

Re: [8] Review request for 7153339: InternalError when drawLine with Xor and Antialiasing

[Oleg Pekhovskiy]

Hi Jim,

first of all I should say, that I prepared that fix for 7u as the most 
safe, with minimum changes.
I agree that getReplacement() should return a valid sufrace or null, but 
it doesn't happen during that switch.


That CR was assigned to me because my previous changes for:
7112642 Incorrect checking for graphics rendering object
7121482 some sun/java2d and sun/awt tests failed with InvalidPipeException
discovered the problem with getReplacement() and were somehow related.

But maybe it would be better to create a separate CR for 
getReplacement() issue and assign it to Java2d Team?
I also could add a comment for "!surfaceData.isValid()" reffering to 
CR7153339.


What do you think?

Thanks,
Oleg

24.08.2012 4:04, Jim Graham wrote:

Hi Oleg,

getReplacement should not be returning an invalid surface.  If the 
current D3DSD is invalid, then it should return a valid replacement. 
The only time it should return null is when the window is gone.  It 
sounds like the window isn't gone here, it has just switched over to a 
non-D3D type of SurfaceData and return that...


...jim

On 8/23/2012 4:37 PM, Oleg Pekhovskiy wrote:

Hi Phil, Jim,

thank you for pointing out the testing work that should be performed.
I tested my fix with the following regression tests:
test/java/awt/Graphics
test/java/awt/Graphics2D
test/java/awt/GraphicsDevice
test/java/awt/GraphicsEnvironment
test/sun/java2d

Plus I tested performance differences on:
demo/jfc/Java2D/Java2Demo.jar

Testing was done on Windows 7 & Ubuntu 12.04 LTS.
No differences were found.

I also asked Yuri Nesterenko to test all that stuff on Mac.

Thanks,
Oleg


11.08.2012 3:10, Phil Race wrote:

Oleg,
This looks OK to me but since this is a shared code change I have
to ask what testing you've done ?

Also why not provide a regression test ? The provided test was
interactive but I think it can be automated.

You need another review and I'd like Jim to take a look.

-phil.

On 8/10/2012 2:26 PM, Oleg Pekhovskiy wrote:

Hi,

Please review the fix for CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7153339

Webrev:
http://cr.openjdk.java.net/~bagiras/8/7153339.1/

Comments:
XOR is not supported for D3D (see comments inside
D3DSurfaceData.validatePipe()) and
software rendering is used invalidating current D3DSurfaceData.
So we have situation when component's peer has invalid SurfaceData
and it's retrieved in
SunGraphics2D.revalidateAll() through SurfaceData.getReplacement()
without any check.
That's why I added validity check there.

Thanks,
Oleg

[8] Review request for 7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo

[Konstantin Shefov]

Hello,

Please review a fix for the issue:

7184326 TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo

Test should be modified in jdk8 to be run via jtreg

The webrev is http://cr.openjdk.java.net/~kshefov/7184326/webrev.00/


Thanks,
Konstantin