Looks good. +1
...jim
On 08/15/2016 08:47 AM, Alexander Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8151303/webrev.04
The MRCI.sizes arrays is reused for for MultiResolutionCachedImage.
Thanks,
Alexandr.
On 11/08/16
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8151303/webrev.04
The MRCI.sizes arrays is reused for for MultiResolutionCachedImage.
Thanks,
Alexandr.
On 11/08/16 23:10, Jim Graham wrote:
Hi Alexandr,
Should something be done to transfer the array of sizes to the
Hi Alexandr,
Should something be done to transfer the array of sizes to the new
instance if the source is an MRCI? Perhaps a special case for MRCI as
well that calls mrciInstance.map(mapper) instead of constructing a brand
new object from scratch?
...jim
On
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8151303/webrev.03
MultiResolutionToolkitImage handing is added to the
MultiResolutionCachedImage.map() method.
Thanks,
Alexandr.
On 11/08/16 01:46, Jim Graham wrote:
Ah, yes, only ToolkitImages can be "not yet loaded"
Ah, yes, only ToolkitImages can be "not yet loaded" in that manner.
A quick look suggests that a MRCI should not be an instance of MRTI, but MRCI.map() does not force its argument to be an
instance of MRCI, just MRI, so it would be possible for someone to pass an MRTI to MRCI.map() and then it
On 09/08/16 03:49, Jim Graham wrote:
Does MultiResolutionCachedImage.map() work if the Image hasn't been
loaded yet (where getWidth/Height(Observer) can return -1)? Can it
ever be called in a case like that?
Could we rely on the fact that getWidth/Height(Observer) returns -1 only
for
Does MultiResolutionCachedImage.map() work if the Image hasn't been
loaded yet (where getWidth/Height(Observer) can return -1)? Can it ever
be called in a case like that?
...jim
On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote:
Just a friendly reminder.
Thanks,
Alexandr.
Looks good to me .. +1
-phil.
On 08/08/2016 12:48 PM, Alexander Scherbatiy wrote:
Just a friendly reminder.
Thanks,
Alexandr.
On 27/06/16 22:17, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8151303/webrev.02
The fix
Just a friendly reminder.
Thanks,
Alexandr.
On 27/06/16 22:17, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8151303/webrev.02
The fix does not use a new public API to apply filters to
multi-resolution images.
Another reason to avoid new API is that we don't have to involve the CCC to get this
"bug fix" in...
...jim
On 5/13/16 3:50 PM, Jim Graham wrote:
That looks very tight. The only issue I'd have is that it would be better if
this could be done with non-public API for
That looks very tight. The only issue I'd have is that it would be better if this could be done with non-public API for
now - the map() methods could live on one of the sun.awt.image classes or even in a Swing implementation utility class
and still work just fine. When we have more time to
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8151303/webrev.01
There was a suggestion to postpone the fix for the issue 8152309
Seamless way of using image filters with multi-resolution images
and continue with the current one:
We could do that for our own filters, but any random custom filter could
run into the same issue, so it might not make sense to upgrade the
existing filter mechanism to always attempt to do MR filtering. We
could either create a parallel set of MR-aware filter mechanisms (such
as the
The one more thing is that image filters should also be updated to use
them with multi-resolution images.
For example, consider the case:
--
Image mrImage = getMultiResolutionImage();
ImageProducer mriProducer = new
FilteredImageSource(mrImage.getSource(), new
On 15/03/16 18:06, Sergey Bylokhov wrote:
On 15.03.16 17:01, Alexander Scherbatiy wrote:
One update will be that FilteredImageSource should implement
MultiResolutionImageProducer even it is used for non multi-resolution
images.
The MRI can be created using two general ways: using fixed
On 12/03/16 00:15, Jim Graham wrote:
Is this tied in with ImageFilter/FilteredImageSource?
It looks like since FIS takes only a Producer, it has lost the handle
to the image to get a source for a particular resolution. What happens
if we introduce MultiResolution[Image]Producer? It would
On 15.03.16 17:01, Alexander Scherbatiy wrote:
One update will be that FilteredImageSource should implement
MultiResolutionImageProducer even it is used for non multi-resolution
images.
The MRI can be created using two general ways: using fixed number of
resolution variants or generating
Is this tied in with ImageFilter/FilteredImageSource?
It looks like since FIS takes only a Producer, it has lost the handle to
the image to get a source for a particular resolution. What happens if
we introduce MultiResolution[Image]Producer? It would provide a single
method that would
On 09/03/16 16:58, Sergey Bylokhov wrote:
Probably we should enhance ImageProducer/Tk.createImage/ImageFilter to
support this functionality? It seems that the number of usage of this
check "image instanceof MultiResolutionImage" will grow over time.
ImageProducer produces pixels for an image
19 matches
Mail list logo
