> On Mar 11, 2016, at 6:27 AM, Alexander Scherbatiy
> wrote:
>
>
> Hello Alan,
>
> Thank you for the feedback.
>
> On 04/03/16 19:59, Alan Snyder wrote:
>> I am writing to share some thoughts based on recent experience using
>> multiresolution images. My experience was not entirely pleasant
Jim,
Here are MapBench results comparing Marlin 0.7.3.2 (before) vs patched
0.7.3.3 (latest patch) on JDK 1.8_72:
Synthetic results:
Tests36121212
Threads4124
Before = Marlin 0.7.3.2:
*Med168.535165.403166.940173.263 *
*Pct95170.256166.0
Jim,
Here is a webrev illustrating my 'simple' approach:
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144938.1/
Changes:
- MarlinRenderingEngine.strokeTo(): removed outat ie always call
src.getPathIterator(at)
that ensures Marlin is working in device-space coordinates; so pathTo() can
filt
Hi Laurent,
On 3/11/16 9:06 AM, Laurent Bourgès wrote:
By the way I started refactoring MRE.strokeTo () to get rid of outat ie
I propose to remove the optimisation for non-uniform at as I prefer
filtering transformed coordinates once even if it requires invDelta /
Delta transform stages in the p
Oops. Fixed : http://cr.openjdk.java.net/~prr/8055463.1/
-phil.
On 03/11/2016 12:22 PM, Sergey Bylokhov wrote:
Hi, Phil.
The FileFont.java contains debug code:
System.out.println("COUNT="+count);
System.out.println("FILE="+fontFile);
On 11.03.16 2:02, Phil Race wrote:
PS there are a couple
Hi, Phil.
The FileFont.java contains debug code:
System.out.println("COUNT="+count);
System.out.println("FILE="+fontFile);
On 11.03.16 2:02, Phil Race wrote:
PS there are a couple of other test files updated here
BigFont is one of the tests I ran whilst checking I didn't create
regressions
an
Hi Laurent,
On 3/11/16 9:06 AM, Laurent Bourgès wrote:
Since this change will solve the issue for fills and uniform-scaled draws(), it
handles the 90% case, but if you use a non-uniform scale of more than 2x, then
it will still allow overflow in the final rendered path if a coordinate is near
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 mimic
Thanks!
...jim
On 3/10/16 10:19 PM, Jayathirth D V wrote:
Hi Jim,
I have replaced wildcard imports with specific import and shared webrev to
Prasanta before pushing. Please find the webrev that is pushed for reference.
http://cr.openjdk.java.net/~jdv/8139183/webrev.07/
Thank
Hello,
I need one more reviewer for the fix.
On 2/15/2016 11:24 AM, Jim Graham wrote:
Thanks Alexandr,
The AWT changes all look good.
I'll leave it to others as to whether the test case represents the
best way to test this. I have no idea how those two font values in
those two L&F's in
Jim,
Thanks for your comments.
I agree the filtering algorithm is not very obvious with too many flags
(skip, pathClosed, subpathStarted) that represent lots of conditionnal
statements and possibly corner cases. If I have time, I may try simplify it
but in a second step.
I will a new tests for c
Hello Alan,
Thank you for the feedback.
On 04/03/16 19:59, Alan Snyder wrote:
I am writing to share some thoughts based on recent experience using
multiresolution images. My experience was not entirely pleasant. I am using JDK
8, although I see no relevant differences in JDK 9.
One of the
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
Please find modified webrev with updated testcase.
http://cr.openjdk.java.net/~psadhukhan/8151590/webrev.01/
Regards
Prasanta
On 3/10/2016 4:04 PM, prasanta sadhukhan wrote:
Hi Phil,
Bug: https://bugs.openjdk.java.net/browse/JDK-8151590
webrev: http://cr.openjdk.java.net/~psadhukhan/8151590/we
Looks fine, and works well.
-yan
On 03/11/2016 02:34 PM, prasanta sadhukhan wrote:
Hi Yuri, All,
Bug: https://bugs.openjdk.java.net/browse/JDK-8151621
webrev: http://cr.openjdk.java.net/~psadhukhan/8151621/webrev.00/
It seems when the testcase is executed through jtreg, the main thread
finish
Hi Yuri, All,
Bug: https://bugs.openjdk.java.net/browse/JDK-8151621
webrev: http://cr.openjdk.java.net/~psadhukhan/8151621/webrev.00/
It seems when the testcase is executed through jtreg, the main thread
finishes without waiting for any user action.
Added a sleep time and modified the testcase
16 matches
Mail list logo