On 01/04/16 06:24, Jim Graham wrote:
Hi Alexandr,
Is there a bug filed to upgrade JLightweightFrame to allow non-integer
(and X/Y) scales? We'd need this capability to implement "Swing
embedded in FX" correctly on Win8.1+...
I have created JDK-8153522 Update JLightweightFrame to allow
no
Hi Alexandr,
Is there a bug filed to upgrade JLightweightFrame to allow non-integer
(and X/Y) scales? We'd need this capability to implement "Swing
embedded in FX" correctly on Win8.1+...
...jim
On 9/22/2015 2:33 AM, Alexander Scherbatiy wrote:
Hello,
Could you re
Note that the test case in JDK-8069348 seems to work OK for a scaled
graphics (it actually fails only if I set the uiScale to 1 for some
reason), but Swing scrolling is completely broken. I dug down to the
call to D3D->StretchRect and it was returning D3DERR_INVALIDCALL and
simply not doing an
I ran SwingSet2 and JDK-8069348 immediately jumped out as being broken
to the point where SwingSet2 was not usable. We should definitely make
that a high priority to fix ASAP. There were a couple of other very
minor rendering issues, but they didn't really affect usability like
that bug...
Hello,
I have filled additional issues which has been discussed on the review:
JDK-8076545 Text size is twice bigger under Windows L&F on Win 8.1
with HiDPI display
JDK-8142966 Wrong cursor position in text components on HiDPI display
JDK-8142961 Position, size and distance sca
Hi Alexandr,
On 11/11/15 3:08 AM, Alexander Scherbatiy wrote:
On 11/10/2015 10:41 PM, Jim Graham wrote:
In drawHiDPIImage, in the VolatileImage case you ignore the transform,
but I suppose that is OK because you pass it through to the
scaleImage() case. However if it came in with a transform t
On 11/11/15 3:08 AM, Alexander Scherbatiy wrote:
For some reasons the link to the latest webrev and comments are not
mentioned in this email.
I found it. I view this mailing list in threaded form and that email on
11/5 did not associate itself with the existing email thread...
The latest version looks fine to me.
A few notes.
- SG2D.drawHiDPIImage does not take into account that
MultiResolutionImage can contain VolatileImages.
- Probably it will be better to move all code related to up/down scale
from SG2D to the DrawImagePipe, which sometimes uses scaled coordinates
On 11/10/2015 10:41 PM, Jim Graham wrote:
In drawHiDPIImage, in the VolatileImage case you ignore the transform,
but I suppose that is OK because you pass it through to the
scaleImage() case. However if it came in with a transform then the
asserts at the top of scaleImage may fail? Maybe it w
In drawHiDPIImage, in the VolatileImage case you ignore the transform,
but I suppose that is OK because you pass it through to the scaleImage()
case. However if it came in with a transform then the asserts at the
top of scaleImage may fail? Maybe it would be better to actually handle
the "non
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8073320/webrev.03/
See my comments inline:
On 10/23/2015 3:27 AM, Jim Graham wrote:
I only read the code portions I commented on below and the ones you
indicated you had changed. I'm assuming there are no ot
On 22.10.15 18:28, Alexander Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8073320/webrev.02/
On 10/21/2015 5:40 PM, Sergey Bylokhov wrote:
I have two small suggestions:
- Probably it will be better to move the new properties from
Win32Graphic
We don't even support EXIF or TIFF at all yet (hope to have it in 9) and
that does
have EXIF data processing support but we would be talking an incredibly
heavyweight process to determine that and figure out how it maps to what
image you want. Being able to tell from the filename is probably 100,
Hey Jim,
I had assumed the code was for still for MRI. And in that context EXIF would
have made more sense. My bad. Sorry for the noise.
-hendrik
> On Oct 24, 2015, at 02:29, Jim Graham wrote:
>
> Hi Hendrik,
>
> The comment I was making was on the format of the command line arguments we
>
Hi Hendrik,
The comment I was making was on the format of the command line arguments
we use to override DPI scaling and has nothing to do with image loading.
You are correct that we don't really deal with the EXIF tags currently,
but I am not sure that they represent something we should be de
> The reason for this is both to have an explicit token for the regular scale
> factor and also so that this matches with the default image suffix of "@2x"
> so that we can add more ways to provide alternate media such as "@120dpi"
> which are consistent with the values we use here.
>
> BTW, w
Note that I still have outstanding comments in my other review email on
webrev.01 - the comments below were only about the indicated changes you
did for Sergey...
...jim
On 10/22/15 5:34 PM, Jim Graham wrote:
The changes look fine to me. I'm OK with deferring on the r
The changes look fine to me. I'm OK with deferring on the rounding of
the scaleDown as long as we don't let it fall between the cracks. For
one thing, it will probably require some additional testing to gauge its
effects and determine the best strategy for rounding down...
I agree with both of these comments...
...jim
On 10/21/15 7:40 AM, Sergey Bylokhov wrote:
I have two small suggestions:
- Probably it will be better to move the new properties from
Win32GraphicsDevice.java to SunGraphicsEnvironment.java, at least
"sun.java2d.uiScale" s
I only read the code portions I commented on below and the ones you
indicated you had changed. I'm assuming there are no other code changes
in this webrev...?
This is getting really close to final which is good since I'll be
talking about this in my JavaOne talk next week... ;)
In SG2D.scal
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8073320/webrev.02/
On 10/21/2015 5:40 PM, Sergey Bylokhov wrote:
I have two small suggestions:
- Probably it will be better to move the new properties from
Win32GraphicsDevice.java to SunGraphicsEnvironment.java, at l
I have two small suggestions:
- Probably it will be better to move the new properties from
Win32GraphicsDevice.java to SunGraphicsEnvironment.java, at least
"sun.java2d.uiScale" should be implemented on linux, and can be
implemented on osx later.
- I am worried about a rounding in
awt_Win32G
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8073320/webrev.01/
- xform is concatenated with transform in SG2D.getResolutionVariant()
method
- imagepipe.transformImage() is used for drawImage(Image,
AffineTransform,...) case
- scale factors are made final in Bu
Hi Alexandr,
Just 2 potential issues I found:
SG2D.java - getResolutionVariant() doesn't take a transform so it can't
take into account the scaling in the transform handed to drawImage(img,
xform). We can leave that as a follow-on bug fix (it won't do bad
things, but it may not pick the best
24 matches
Mail list logo
