[OpenJDK 2D-Dev] <AWT Dev> [8] Request for review: 8000629 [macosx] Blurry rendering with Java 7 on Retina display

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Apr 9 02:54:28 PDT 2013

Hi, Jim.
On 4/9/13 1:19 AM, Jim Graham wrote:
> Hi Sergey,
> Did you check for possible performance hits for the new transform 
> save/compare code in BufferedContext?
I am not sure how it can be improved, because BufferedPaints.setPaint() 
depends from the current transform of the sg2d.transform. And it should 
be called, when sg2d.transform is changed.
> That is significantly more work per validate(). 
I guess in most common case only aftm.equals() was added.
> Also, isn't this case only used in the case where the caller specified 
> a null xform in the argument list?  Does that happen (or, I guess, how 
> does it happen) on a scaled graphics?
Yes this happens if xform is null, so only code under if (xform == 
null)  was changed.
> Something I didn't notice before - you adjust the max texture sizes in 
> CGLGraphicsConfig by the device scale, but you adjust them by 
> "getScaleFactor() * 2".  Why the "* 2"?
This is related to 7160609. The problem was in fact, that we create huge 
texture during window initialization. In the fix I change this logic to 
Separate CR:8010999 was created to track it.
> You removed a call to flushOnScreenGraphics in LWWindowPeer.  Was that 
> just being paranoid before and really isn't needed?
Now it is called not only when the window is resized, but when the 
surface is replaced. It was moved to replaceSurfaceData.
> It's already done and the code is written, but in retrospect, I'm not 
> sure how much the optimizations in getTransform/setTransform are worth 
> compared to the easy readability of having the transforms done 
> linearly in a LIFO manner, such as:
> setTransform:
>     transform.setToIdentity();
>     if (cX|cY != 0) { transform.translate(cX, cY); }
>     if (dS != 1) transform.scale(dS, dS); }
>     transform.concatenate(Tx);
> getTransform:
>     tx = new AT(transform);
>     if (dS != 1) { tx.scale(invDs, invDs); }
>     if (cX|cY != 0) { tx.translate(-cX, -cY); }
>     return tx;
> (I don't think it should be changed, but I'm throwing it out there as 
> food for thought as it may be easier to maintain in the future, but it 
> could also change the performance as I'm just speculating from how I 
> remember the optimizations work...)
When it was written, I was impressed by a code in the 2D.
>             ...jim
> On 4/8/2013 6:10 AM, Sergey Bylokhov wrote:
>> Hi, Phil, JIm.
>> New version of the fix:
>> http://cr.openjdk.java.net/~serb/8000629/webrev.08
>>   - Assumption that we should scale all native surfaces was wrong. In 
>> case of managed Bufferedimage we shouldn't scale native surface, 
>> because they are copies 1-1.(CGLSurfaceData.java:60).
>>   - BufferedContext is not always updates current Paint, because it 
>> checks transX/transY from sg2d, which is not maintained in the scale 
>> mode.
>> Test: FillTexturePaint.java
>> Also I found a problem in the sg2d.getTransform(), where invScale 
>> does not apply to constrainX/Y.
>> Test: TransformSetGet.java
>> On 4/5/13 10:00 PM, Phil Race wrote:
>>> SFAIK you haven't fixed the problem with TexturePaint I pointed out 
>>> last week.
>>> That needs to be fixed before you push.
>>> -phil.
>>> On 4/5/2013 9:54 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> I assume, that you haven't additional comments? Can I consider you 
>>>> as the second reviewer?
>>>> Note that I plan push it to awt-dev because, my other fixes depend 
>>>> on it.
>>>> On 3/26/13 7:33 PM, Sergey Bylokhov wrote:
>>>>> Hello,
>>>>> Please review the fix for jdk 8.
>>>>> Change adds initial support of hidpi(mostly on 2d side). In the 
>>>>> fix scale was added to the surface data/CGraphicsDevice /CGLLayer. 
>>>>> This scale factor maps virtual coordinates to physical pixels.
>>>>> This change doesn't add support of hidpi to aqua l&f and doesn't 
>>>>> add support of dynamic change of scale factor.
>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000629
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8000629/webrev.06
>>>>> -- 
>>>>> Best regards, Sergey.
>>>> -- 
>>>> Best regards, Sergey.
>> -- 
>> Best regards, Sergey.

Best regards, Sergey.

More information about the macosx-port-dev mailing list