[OpenJDK 2D-Dev]  request for review: 7124347: [macosx] "java.lang.InternalError: not implemented yet" on call Graphics2D.drawRend
andrew.brygin at oracle.com
Fri Nov 30 09:37:53 UTC 2012
I have verified that we use either the imageComp field from SunGraphics2D
(which can not be null), or some explicit composite type in this method.
So, according to your suggestion, I have removed the check for null.
Please take a look to updated webrev:
Phil, could you please take a look the the updated fix also?
On 30.11.2012 4:48, Jim Graham wrote:
> Hi Andrew,
> My belief is that comp should never be null. A simple grep should
> confirm that belief. While I do agree that it can be safer to check
> for null if you aren't sure about the code base, once one piece of
> code does it then it spreads and weakens the API contract so it would
> be better to check and keep the API contract stronger if we can...
> On 11/29/12 12:18 AM, Andrew Brygin wrote:
>> Hello Jim,
>> I do not think that suggested change allows a null composite per se:
>> the check for null was introduced just to make sure that we can safely
>> call isDerivedFrom method. However, it does not change the method
>> behavior for the case of null composite.
>> If it is impossible to get null composite here for some reason
>> I can not say this for sure), then this check is not required.
>> However, I do not
>> think that the extra check for null may cause any harm.
>> On 29.11.2012 4:07, Jim Graham wrote:
>>> Is there a reason for allowing a null comp in the isSupported method?
>>> On 11/26/2012 4:38 AM, Andrew Brygin wrote:
>>>> could you please review a fix for 7124347?
>>>> This fix does not implement getRater() in ogl surfaces.
>>>> Instead, it provides a blit for custom composite, which
>>>> prepares a snapshot of the destination surface (which
>>>> is one of ogl surfaces) and delegates the work to the
>>>> general blit, which now extracts raster from the snapshot.
>>>> A result of general blit's work is transferred to the
>>>> original destination.
>>>> Changes in OGLSurfaceDataProcy are required in order to prevent
>>>> getting an accelerated copy of original source image as an
>>>> operand of the blit. Now we first check for composite type,
>>>> and only then (if composite is not specified, or is a kind
>>>> of alpha composite) we take into account other conditions.
>>>> So this fix does not change anything for the case of alpha
>>>> but affects only XOR and custom composites case.
>>>> Note that the fix solves the problem only for the case of blits
>>>> (i.e. drawImage()). Other operations may result into the same
>>>> problem if custom composite is used. However, in case of XOR,
>>>> this change solves the problem completely, because other rendering
>>>> operations in the ogl pipeline are ready for XOR composite.
>>>> Supplied regression test verifies that the fix makes the problem
>>>> I have verified both windows and macosx platforms.
>>>> Please take a look and share your comments.
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124347
>>>> Webrev: http://cr.openjdk.java.net/~bae/7124347/8/webrev.00/
More information about the 2d-dev