Hi Phil,
Could you look at the two suggested ways of the multi-resolution
image support API implementation?
Thanks,
Alexandr.
On 8/20/2014 8:10 PM, Alexander Scherbatiy wrote:
Hi Phil,
I have prepared the fix where resolution variants are added directly
to the Image:
Hi Phil,
I have prepared the fix where resolution variants are added directly
to the Image:
http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
You could compare this with the previous version where
MultiResolutionImage interface is used:
Just friendly remainder.
Thanks,
Alexandr.
On 7/8/2014 7:02 PM, Alexander Scherbatiy wrote:
Hi Phil,
Could you review the fix?
Thanks,
Alexandr.
On 6/11/2014 7:18 PM, Alexander Scherbatiy wrote:
Hi Phil ,
I just prepared a simple FAQ about the Custom MultiResolution
Hi Phil,
On 5/16/2014 9:12 PM, Phil Race wrote:
I think Jim was looking at this. I am not sure if you yet answered all
his questions/concerns.
There's a lot of API here and it will take more time than I have right
now just to get
my head around it so do not expect a quick answer.
1. Why
Hi Phil,
I need a reviewer from the 2d group for the fix. Could you take a
look at the fix and review it?
Thanks,
Alexandr.
On 5/12/2014 6:35 PM, Alexander Scherbatiy wrote:
There was a long thread about the image with sub-pixel resolution
drawing on Mac OS X:
I think Jim was looking at this. I am not sure if you yet answered all
his questions/concerns.
There's a lot of API here and it will take more time than I have right
now just to get
my head around it so do not expect a quick answer.
1. Why is there no javadoc on the new API on Toolkit ?
2.
There was a long thread about the image with sub-pixel resolution
drawing on Mac OS X:
http://mail.openjdk.java.net/pipermail/macosx-port-dev/2013-April/005559.html
It was pointed out that Icon images that can be programmatically
generated also need to have HiDPI support:
On 4/25/2014 2:17 AM, Jim Graham wrote:
Hi Alexandr,
I asked for who was requesting these facilities and you responded with
the solution you are planning to provide.
I don't care what the solution looks like if we have nobody asking for
the feature - I am asking who is asking for these
Hello,
I have decided to split the current issue on two parts:
- 8029339 Custom MultiResolution image support on HiDPI displays
that covers only MultiResolutionImage interface and
AbstractMultiResolutionImage class realization
- 8041714 Add methods that create MultiResolutionImage
Hi Alexandr,
I asked for who was requesting these facilities and you responded with
the solution you are planning to provide.
I don't care what the solution looks like if we have nobody asking for
the feature - I am asking who is asking for these capabilities?
On 4/3/2014 2:23 AM, Jim Graham wrote:
Hi Alexandr,
The back and forth is getting confusing here, so I thought I'd try to
summarize and start fresh(ish):
1. We need to support @2x internally for MacOS compatibility (done).
2. We will need to support _DPI images for Win-DPI compatibility
Hi Alexandr,
The back and forth is getting confusing here, so I thought I'd try to
summarize and start fresh(ish):
1. We need to support @2x internally for MacOS compatibility (done).
2. We will need to support _DPI images for Win-DPI compatibility (TBD).
3. Customers may have their own
Below are some thoughts about TK.createMRImage(...) method
On 3/24/2014 4:52 PM, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
- baseImageWidth/Height arguments are added to the
getResolutionVariant(...)
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.03/
- baseImageWidth/Height arguments are added to the
getResolutionVariant(...) method
- dest image sizes are reverted to included DPI scale
- AbstractMultiResolutionImage is added. It
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.02/
- transform is removed from the getResolutionVariant(...) method
- width/height args from the getResolutionVariant(...) are renamed
to destImageWidth/destImageHeight
- I have not
Hi Alexandr,
On 3/21/14 7:33 AM, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8029339/webrev.02/
- transform is removed from the getResolutionVariant(...) method
I notice that you reverted the changes to SG2D so
Hi, Alexander.
Probably it will be better to provide device transform to the user
instead of float logicalDPIX, float logicalDPIY?
It is unclear what does it mean width for example. It is initial width
of the image, or width after transformation?
On 3/20/14 6:52 PM, Alexander Scherbatiy
Hi Alexandr,
SG2D leaks its internal transform to the implementation. A clone must
be created to prevent breaking encapsulation of graphics state. The
clone raises the cost of calling the interface so we need to evaluate
how important it is to have the transform be included in the
It appears to be the destination size of the image, but only taking the
scaling parameters of the drawImage() method signature into account (not
the transform).
I'd rather see the full destination size (including both scaling in the
drawImage parameters and the transform) provided as that can
19 matches
Mail list logo
