I am now fine with this latest version.
-phil.
On 10/4/13 12:21 PM, Sergey Bylokhov wrote:
Hi, Jim, Phil.
Once again=) I assume, that you haven't additional comments? Can I
consider you as the reviewers?
Note that I plan push it to awt-dev because, my other fixes depend on it.
On 4/5/13 10:1
I took one last glance through the .06 webrev. I don't see any more
issues...
...jim
On 10/4/13 12:21 PM, Sergey Bylokhov wrote:
Hi, Jim, Phil.
Once again=) I assume, that you haven't additional comments? Can I
consider you as the reviewers?
Note that I plan push it to awt-dev
I skimmed the updated version but I haven't had a chance to try it out yet.
I'll try to do so later today or tomorrow.
-phil.
On 10/4/2013 12:21 PM, Sergey Bylokhov wrote:
Hi, Jim, Phil.
Once again=) I assume, that you haven't additional comments? Can I
consider you as the reviewers?
Note tha
Hi, Jim, Phil.
Once again=) I assume, that you haven't additional comments? Can I
consider you as the reviewers?
Note that I plan push it to awt-dev because, my other fixes depend on it.
On 4/5/13 10:10 PM, Sergey Bylokhov wrote:
Hi, Phil.
Could you please send me a screenshot and steps to rep
Hi, Jim.
During additional testing I found some artifacts in some animation, when
the rendering to the scaled VolatileImge is different from the non
scaled variant. Can you please take a look to the CR:8011764.
On 4/9/13 1:19 AM, Jim Graham wrote:
Hi Sergey,
Did you check for possible perfor
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
I just wanted to add:
On 4/8/2013 2:19 PM, Jim Graham wrote:
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, su
Hi Sergey,
Did you check for possible performance hits for the new transform save/compare
code in BufferedContext? That is significantly more work per validate().
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,
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
Hi, Phil.
Could you please send me a screenshot and steps to reproduce.
Note that you should change hidpi mode before start j2ddemo.
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
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
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(
I've been trying out the patch - using quartz debug, since I don't have
a retina display.
Aside from occasional artifacts in theSwing controls which may well be
code there
that doesn't handle this case well, the only pure 2D thing that I
noticed was the
Texture Paint demos in Java2Demo don't s
I don't think the constant would add any value and would just cause someone looking over
the code to wonder what kind of magical value means NO_SCALE when the value is so
obvious. I think anyone can realize that 1 or 1.0 means "not scaling" with
about 2 neurons firing. The mystery created by
Hi Sergey,
The fix looks ok. But I have two ideas.
1.) We use everywhere 1 as a measure of scale.Would not it be better to
use a constant at least for integer values? Actually, as far as we
dealing with 1.0 we should not have any issues with precision. On the
other hand, the widening primiti
OK. Thanks for filing the bug.
--
best regards,
Anthony
On 03/28/13 16:37, Sergey Bylokhov wrote:
This only applies to a few specific applets,
Most of our demos just does not work, because of that I leave it here.
and the problem is not directly related to HiDPI support because
you'll run i
This only applies to a few specific applets,
Most of our demos just does not work, because of that I leave it here.
and the problem is not directly related to HiDPI support because
you'll run into a similar bug when running with a LoDPI native
resolution of, say, 640x480 or 800x600. Therefore
On 03/27/13 20:12, Sergey Bylokhov wrote:
On 3/27/13 6:52 PM, Anthony Petrov wrote:
(there's also other usages of int in shared code)
Why do we use integer values here? There's no 100% guarantee that the
scale factor is integer on Mac (or other platforms when we support
HiDPI rendering on them).
On 3/28/13 1:04 PM, Denis S. Fokin wrote:
Hi Sergey,
actually, the round function has a little bit more complicated
implementation because of 6430675.
Here is the new version:
http://cr.openjdk.java.net/~serb/8000629/webrev.07
Thank you,
Denis.
On 3/27/2013 7:15 PM, Sergey Bylokhov wr
On 3/28/13 1:04 PM, Denis S. Fokin wrote:
Hi Sergey,
actually, the round function has a little bit more complicated
implementation because of 6430675.
Thanks for pointing this, I'll change the code.
Thank you,
Denis.
On 3/27/2013 7:15 PM, Sergey Bylokhov wrote:
On 3/27/13 4:12 PM, De
On 3/27/13 6:52 PM, Anthony Petrov wrote:
(there's also other usages of int in shared code)
Why do we use integer values here? There's no 100% guarantee that the
scale factor is integer on Mac (or other platforms when we support
HiDPI rendering on them). At least native APIs operate with float
On 3/27/13 4:12 PM, Denis S. Fokin wrote:
Hi Sergey,
why we do not use Math.round() here?
Region.java:
153 return (int) Math.floor(newv + 0.5);
Just because it one additional call.
Thank you,
Denis.
On 3/26/2013 7:33 PM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jd
Hi Sergey,
src/macosx/classes/sun/java2d/opengl/CGLLayer.java
48 private int scale = 1;
src/macosx/classes/sun/awt/CGraphicsDevice.java
222 public int getScaleFactor() {
src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
45 protected final int scale;
(there's also o
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
24 matches
Mail list logo
