Hi Sergey,
Looks good to me.
Regards,
Anton.
On 12.03.2015 4:40, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8/9.
Lots of issues(hangs or focus lost) occurred after we call NSScreen.backingScaleFactor on a Appkit
Thread in time of splash screen initialization.
This is a
. Tarasov wrote:
On 22.05.2014 15:36, Sergey Bylokhov wrote:
On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
Hi Sergey,
On 22.05.2014 1:44, Sergey Bylokhov wrote:
On 5/21/14 10:13 PM, Anthony Petrov wrote:
Hi Sergey,
The original fix provides some updates and clarifications to the javadoc
anymore.
Ok, this is about a matter of taste. The 5th point sounds strong enough for me, so I'm fine with the
current version.
Thanks!
Anton.
--
best regards,
Anthony
On 5/23/2014 2:11 PM, Anton V. Tarasov wrote:
Hi Sergey,
Thanks for the update. I'm fine with the fix, except one thing. (I'm
On 2/17/14 6:09 AM, Anton V. Tarasov wrote:
Jim, so this is ready for a push then.
Thanks!
Anton.
On 15.02.2014 5:01, Jim Graham wrote:
I don't need to see an update for that. I didn't read the entire
webrev, but I looked at this one piece of code and if that was the
only thing changed then I
On 22.05.2014 15:36, Sergey Bylokhov wrote:
On 5/22/14 11:47 AM, Anton V. Tarasov wrote:
Hi Sergey,
On 22.05.2014 1:44, Sergey Bylokhov wrote:
On 5/21/14 10:13 PM, Anthony Petrov wrote:
Hi Sergey,
The original fix provides some updates and clarifications to the javadoc
issues...
...jim
On 2/13/14 11:12 PM, Anton V. Tarasov wrote:
On 14.02.2014 2:52, Jim Graham wrote:
On 2/13/14 5:03 AM, Anton V. Tarasov wrote:
Hi Jim,
Please, look at the update:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.5
Here I'm correcting the rect after the transform
.)
...jim
On 2/11/14 10:10 AM, Anton V. Tarasov wrote:
Hi Jim,
On 2/11/14 4:12 AM, Jim Graham wrote:
Just out of curiosity, on a Mac there is support for @2x images where
they get loaded and used (at half scale to preserve layout size)
automatically for you. In that respect, the added resolution
by
SurfaceData.getDefaultScale() which was int.
Thanks,
Anton.
...jim
On 2/10/14 3:37 PM, Jim Graham wrote:
On 2/10/14 6:11 AM, Anton V. Tarasov wrote:
On 2/3/14 6:36 AM, Anton V. Tarasov wrote:
In SG2D, the drawHiDPIImage, for instance, makes a call to
op.filter(img, null); where
on it.
Otherwise, I didn't spot any other issues...
Glad to hear that :)
On 2/3/14 6:36 AM, Anton V. Tarasov wrote:
In SG2D, the drawHiDPIImage, for instance, makes a call to
op.filter(img, null); where the img is expected to return its layout
size. That's why I still prefer to use
, Anton V. Tarasov wrote:
Hi Jim,
Please look at the updated version:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.4
On 01.02.2014 5:35, Jim Graham wrote:
Hi Anton,
On 1/31/14 6:37 AM, Anton V. Tarasov wrote:
My understanding is that, unless the fix is absolutely irrelevant (whic
I hope
On 1/24/14 6:47 AM, Anton V. Tarasov wrote:
Hi Anthony,
I see your concern. I'll think of a better name.
Thanks,
Anton.
On 24.01.2014 15:47, Anthony Petrov wrote:
Hi Anton,
I suggest to rename the OffscreenHiDPIImage.hidpiEnabled and its
corresponding setter/getter to something like
AM, Anton V. Tarasov wrote:
Hi all,
Let me please resume the review process.
With the new webrev:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.3
I'm addressing the last concern which was about leaking the internal
OffscreenHiDPIImage to the public via RepaintManager.getOffscreenBuffer
that it's clear what this
boolean flag does just by looking at its name.
--
best regards,
Anthony
On 1/21/2014 5:29 PM, Anton V. Tarasov wrote:
Hi all,
Let me please resume the review process.
With the new webrev:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.3
I'm addressing the last
. This was what I was worried
about in terms of one of these internal double buffers leaking to developer code. If they test
the image using instanceof they will see that it is a BufferdImage and they may try to dig out the
raster and get confused...
...jim
On 12/17/13 10:21 AM, Anton V
look at it deeper.
Thanks,
Anton.
...jim
On 12/18/13 1:25 AM, Anton V. Tarasov wrote:
Hi Jim,
Thanks for noticing (sorry, but I simply forgot to check we don't export
the buffer...) What can we do about that? I have the following thoughts:
1) We can warn developers to be ready
.
On 17.12.2013 22:21, Anton V. Tarasov wrote:
Hi all,
Please look at the new version:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
It contains the following changes:
- All the scale related stuff is moved to the new class:
OffScreenHiDPIImage.java
- JViewport and RepaintManager no longer
in terms of one of these internal double buffers leaking to developer code. If they test
the image using instanceof they will see that it is a BufferdImage and they may try to dig out the
raster and get confused...
...jim
On 12/17/13 10:21 AM, Anton V. Tarasov wrote:
Hi all,
Please
On 18.12.2013 13:25, Anton V. Tarasov wrote:
Hi Jim,
Thanks for noticing (sorry, but I simply forgot to check we don't export the buffer...) What can
we do about that? I have the following thoughts:
1) We can warn developers to be ready for a HiDPI raster when they call that method under
The 4th option, previously suggested by Sergey, is to switch off double
buffering at all. I'm investigating it.
Thanks,
Anton.
On 12/18/13 1:25 PM, Anton V. Tarasov wrote:
Hi Jim,
Thanks for noticing (sorry, but I simply forgot to check we don't
export the buffer...) What can we do about
Hi all,
Please look at the new version:
http://cr.openjdk.java.net/~ant/JDK-8029455/webrev.2
It contains the following changes:
- All the scale related stuff is moved to the new class:
OffScreenHiDPIImage.java
- JViewport and RepaintManager no longer cache buffers.
- JLightweightFrame has
Summarizing your comments. We can't export a scaled version of a
BufferedImage in the bounds of the current API without violating the
spec. Unless a scaled BufferedImage is used internally, in which case we
are less constrained. Ok, let's try this approach. I searched the code
for all the
On 12/13/13 2:05 AM, Anthony Petrov wrote:
On 12/12/2013 07:18 PM, Anton V. Tarasov wrote:
[cc'ing to j2d alias]
On 11.12.2013 21:29, Sergey Bylokhov wrote:
On 11.12.2013 20:23, Anton V. Tarasov wrote:
- CGraphicsDevice
This setter is only called from
CPlatformLWView.getGraphicsDevice
[cc'ing to j2d alias]
On 11.12.2013 21:29, Sergey Bylokhov wrote:
On 11.12.2013 20:23, Anton V. Tarasov wrote:
- CGraphicsDevice
This setter is only called from CPlatformLWView.getGraphicsDevice(). I've explained it in my
previous message. It's needed to change the scale factor
[cc'ing to j2d]
On 11.12.2013 14:38, Sergey Bylokhov wrote:
On 11.12.2013 13:18, Anton V. Tarasov wrote:
Hi Sergey,
On 11.12.2013 3:26, Sergey Bylokhov wrote:
Hi, Anton.
My expectation was that everything should work automatically, if you get correct CGraphicsDevice
for the embedded swing
[cc'ing to j2d]
On 11.12.2013 23:14, Anthony Petrov wrote:
Hi Anton,
On 12/11/2013 02:40 PM, Anton V. Tarasov wrote:
2. I'm not sure if adding the scale field to the BI is a good idea. I
think that the image shouldn't be aware of any scale. After all, it's
just an image, a bitmap. It has its
[cc'ing to j2d]
On 12.12.2013 1:30, Jim Graham wrote:
On 12/11/13 2:40 AM, Anton V. Tarasov wrote:
On 10.12.2013 23:57, Anthony Petrov wrote:
I think that the image shouldn't be aware of any scale.
The scale field put into the BufferedImage class means that an image
instance should
[cc'ing to j2d]
Jim, let me continue this thread later when a general agreement about a scaled
BufferedImage is made.
Thanks,
Anton.
On 12.12.2013 1:44, Jim Graham wrote:
Hi Anton,
On 12/11/13 5:13 AM, Anton V. Tarasov wrote:
Hi Jim,
On 11.12.2013 13:14, Jim Graham wrote
[cc'ing to j2d]
On 12.12.2013 1:54, Jim Graham wrote:
On 12/11/13 5:13 AM, Anton V. Tarasov wrote:
On 11.12.2013 13:14, Jim Graham wrote:
With the new support for scaled BufferedImages we now have a situation
where some images return their logical dimensions from
getWidth/Height(null
Hi Andrew,
The changes look fine for me in general (though, I'm not an expert in this
area).
Thanks,
Anton.
On 04.03.2013 20:04, Andrew Brygin wrote:
Hello,
could you please review forward port of the fix for 7152608 to jdk8?
Bug: http://bugs.sun.com/view_bug.do?bug_id=7152608
Webrev:
29 matches
Mail list logo
