Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
OK, I see. You were doubting that the "thing that came after Pisces" could be that much different considering that Pisces is rendering many more sub-pixels. Actually, embarrassingly I think it can. It just means the non-AA renderer has some performance issues. One thing I can think of is that the SpanShapeIterator uses a native method call per path segment and the cost of the context switches into native and back for each path segment dominate the performance of long paths. It was something I was meaning to fix for a long time (when that code was first written native code was so much faster than Java and the native transition was quick - since then Hotspot came along, got a lot better, and the native transitions got much, much slower). So, yes, this isn't out of the question... ...jim On 9/2/2010 3:40 PM, Denis Lila wrote: Use which? The stroking code or the rendering code? I believe that the way I set it up was that Pisces replaced both the stroke widening/dashing code and the AA renderer - both were parts that we relied on Ductus for. But, the widening code would talk to one of our other existing rasterizers for non-AA. Look at LoopPipe.draw(sg2d, s). It (eventually) calls RenderEngine.strokeTo() directed at a SpanShapeIterator... I think there's a misunderstanding. All I meant was that, even when AA is off, we do use pisces for widening, but it doesn't do any rasterization. - "Jim Graham" wrote: ...jim On 9/2/2010 3:20 PM, Denis Lila wrote: Do we use Pisces for non-AA? Pisces should clock in slower for AA than non-AA, but I think we use one of the other pipes (not Ductus) for non-AA and maybe it just isn't as good as Pisces? We definitely use it for non-AA. I traced it. Denis. - "Jim Graham" wrote: On 9/2/2010 2:43 PM, Denis Lila wrote: Actually, I had a question about the test I wrote which takes 20 seconds. When I turned antialiasing on, the test dropped from 20 seconds to 2.5. This is very puzzling, since antialiasing is a generalization of non-antialiased rendering (a generalization where we pretend there are 64 times more pixels than there actually are). Of course, the paths followed after pisces for AA and non-AA are completely different, but whatever came after pisces in the non-AA case would have the same input as Renderer has in the AA case (input gotten from Stroker). Can you take a guess as to what was causing such a large difference? I think Pisces was integrated only as a Ductus replacement which means it was used only for AA, but check if I'm mistaken... ...jim
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
> Use which? The stroking code or the rendering code? > I believe that the way I set it up was that Pisces replaced both the > stroke widening/dashing code and the AA renderer - both were parts that > we relied on Ductus for. But, the widening code would talk to one of > our other existing rasterizers for non-AA. Look at > LoopPipe.draw(sg2d, s). It (eventually) calls RenderEngine.strokeTo() > directed at a SpanShapeIterator... I think there's a misunderstanding. All I meant was that, even when AA is off, we do use pisces for widening, but it doesn't do any rasterization. - "Jim Graham" wrote: > ...jim > > On 9/2/2010 3:20 PM, Denis Lila wrote: > >> Do we use Pisces for non-AA? Pisces should clock in slower for AA > than > >> non-AA, but I think we use one of the other pipes (not Ductus) for > >> non-AA and maybe it just isn't as good as Pisces? > > > > We definitely use it for non-AA. > > I traced it. > > > > Denis. > > > > - "Jim Graham" wrote: > > > >> On 9/2/2010 2:43 PM, Denis Lila wrote: > >>> Actually, I had a question about the test I wrote which takes 20 > >> seconds. When > >>> I turned antialiasing on, the test dropped from 20 seconds to > 2.5. > >> This is very > >>> puzzling, since antialiasing is a generalization of > non-antialiased > >> rendering > >>> (a generalization where we pretend there are 64 times more pixels > >> than there > >>> actually are). Of course, the paths followed after pisces for AA > and > >> non-AA are > >>> completely different, but whatever came after pisces in the > non-AA > >> case would > >>> have the same input as Renderer has in the AA case (input gotten > >> from Stroker). > >>> Can you take a guess as to what was causing such a large > >> difference? > >> > > > >> > >> I think Pisces was integrated only as a Ductus replacement which > means > >> > >> it was used only for AA, but check if I'm mistaken... > >> > >>...jim
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Use which? The stroking code or the rendering code? I believe that the way I set it up was that Pisces replaced both the stroke widening/dashing code and the AA renderer - both were parts that we relied on Ductus for. But, the widening code would talk to one of our other existing rasterizers for non-AA. Look at LoopPipe.draw(sg2d, s). It (eventually) calls RenderEngine.strokeTo() directed at a SpanShapeIterator... ...jim On 9/2/2010 3:20 PM, Denis Lila wrote: Do we use Pisces for non-AA? Pisces should clock in slower for AA than non-AA, but I think we use one of the other pipes (not Ductus) for non-AA and maybe it just isn't as good as Pisces? We definitely use it for non-AA. I traced it. Denis. - "Jim Graham" wrote: On 9/2/2010 2:43 PM, Denis Lila wrote: Actually, I had a question about the test I wrote which takes 20 seconds. When I turned antialiasing on, the test dropped from 20 seconds to 2.5. This is very puzzling, since antialiasing is a generalization of non-antialiased rendering (a generalization where we pretend there are 64 times more pixels than there actually are). Of course, the paths followed after pisces for AA and non-AA are completely different, but whatever came after pisces in the non-AA case would have the same input as Renderer has in the AA case (input gotten from Stroker). Can you take a guess as to what was causing such a large difference? I think Pisces was integrated only as a Ductus replacement which means it was used only for AA, but check if I'm mistaken... ...jim
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
> Do we use Pisces for non-AA? Pisces should clock in slower for AA than > non-AA, but I think we use one of the other pipes (not Ductus) for > non-AA and maybe it just isn't as good as Pisces? We definitely use it for non-AA. I traced it. Denis. - "Jim Graham" wrote: > On 9/2/2010 2:43 PM, Denis Lila wrote: > > Actually, I had a question about the test I wrote which takes 20 > seconds. When > > I turned antialiasing on, the test dropped from 20 seconds to 2.5. > This is very > > puzzling, since antialiasing is a generalization of non-antialiased > rendering > > (a generalization where we pretend there are 64 times more pixels > than there > > actually are). Of course, the paths followed after pisces for AA and > non-AA are > > completely different, but whatever came after pisces in the non-AA > case would > > have the same input as Renderer has in the AA case (input gotten > from Stroker). > > Can you take a guess as to what was causing such a large > difference? > > > I think Pisces was integrated only as a Ductus replacement which means > > it was used only for AA, but check if I'm mistaken... > > ...jim
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
On 9/2/2010 2:43 PM, Denis Lila wrote: Actually, I had a question about the test I wrote which takes 20 seconds. When I turned antialiasing on, the test dropped from 20 seconds to 2.5. This is very puzzling, since antialiasing is a generalization of non-antialiased rendering (a generalization where we pretend there are 64 times more pixels than there actually are). Of course, the paths followed after pisces for AA and non-AA are completely different, but whatever came after pisces in the non-AA case would have the same input as Renderer has in the AA case (input gotten from Stroker). Can you take a guess as to what was causing such a large difference? Do we use Pisces for non-AA? Pisces should clock in slower for AA than non-AA, but I think we use one of the other pipes (not Ductus) for non-AA and maybe it just isn't as good as Pisces? I think Pisces was integrated only as a Ductus replacement which means it was used only for AA, but check if I'm mistaken... ...jim
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Hello Jim. > Either way, hopefully the performance is much better now that the > dashing and widening code has to process a lot fewer segments. Is > it? In some cases, it's as much as 20x better. I wrote a small program to draw extremely high numbers of random curves, so that I could test performance, and notice obvious mistakes. This function split a 1000x1000 frame in 100 100x100 squares drew 20 random curves in each of them. I set a stroke with line width = 2, so that pisces would get used. The operation took about 18-20 seconds per frame on my machine. Then I tried a very early version of this changeset (the one where the subdivisions were uniformly spaced, with 5 curves per side), and it took less than 2 seconds. That algorithm was faster, so we can't expect the same gains with the current version (which is actually correct (I think)), but after we do some optimizations it should be close. Actually, I had a question about the test I wrote which takes 20 seconds. When I turned antialiasing on, the test dropped from 20 seconds to 2.5. This is very puzzling, since antialiasing is a generalization of non-antialiased rendering (a generalization where we pretend there are 64 times more pixels than there actually are). Of course, the paths followed after pisces for AA and non-AA are completely different, but whatever came after pisces in the non-AA case would have the same input as Renderer has in the AA case (input gotten from Stroker). Can you take a guess as to what was causing such a large difference? > Are quarter circles easy to detect? Their 2 angles should both be 45 > degrees and their lengths should be similar (I don't think the middle > control segment is the same length as the outer 2, but there is probably > some tolerance where a single subdivision works fine). What I'm doing now is that for every curve, I rotate it so that p2-p1 is parallel to the x-axis. So if the curve was a quarter circle, after the rotation it should be monotonic in both x and y. This is similar to detecting quarter circles by looking at the angles, but it's more general. And, I think, it has the same numerical problems. Because of this, I don't think we should treat them as a special case. But anyway, this isn't a big deal. My main concern with ignoring dx/dt and dy/dt roots outside of (0.001,0.999) was a stylistic one, but it won't really affect correctness much. The worst that can happen is that a curve that bends a tiny bit more than 90 degrees will be widened by 1 curve, instead of 2, which is what we would like. Regards, Denis. - "Jim Graham" wrote: > ...jim > > On 9/2/2010 7:08 AM, Denis Lila wrote: > > Hello Jim. > > > > Sorry for all the e-mails. > > I implemented the rotating version. The rotation introduces small > > numerical errors, so when I solve for the roots of dx/dt and dy/dt, > > the values of t I get are slightly off. So for a rotated quarter > > circle, what happens is that it gives me a root at, say, > t=0.9996... > > so I still end up subdividing quarter circles. I "fixed" this by > > ignoring all roots outside of (0.001,0.999), instead of ignoring > > roots outside of (0,1) which is the ideal solution. I don't like > > hardcoding constants like this. Add to this the higher complexity > > of the rotation, and I'm tempted to say it might be better to just > > bite the bullet on rotated quarter circles and widen them using 2 > > curves per side. > > > > I had one question: what do you think of widening all curves using > > quadratic curves? Their great simplicity might make things safer. > We > > can guarantee that none of the strange behaviour I've seen and > described > > with cubic curves will arise (but we'd have to use more of them). > > > > Also, I've tested the current implementation with a few hundred > random > > cubic paths, and everything looks good so far. > > > > Thanks, > > Denis. > > > > - "Denis Lila" wrote: > > > >> Hello Jim. > >> > >>> I think this would actually ensure that every resulting curve can > >>> be rotated to be made monotonic in both x and y (at least after > >>> inflections are eliminated), which means it's at least as good as > >>> what I have now. > >> > >> While that first statement is true, it unfortunately does not mean > >> it's > >> "at least as good as" breaking the curve into monotonic pieces. I > >> implemented the angle checking method, and the problem is that for > >> curves like (0,0),(1000,1),(-1000,1),(0,0) it is very bad. That's > >> because I implemented it by subdividing at t=0.5, so the angles > >> in the resulting curves' polygons are still wide. After enough > >> subdivisions the polygons would have angles below 45, but that > would > >> defeat the point, since we're trying to minimize the number of > output > >> curves. > >> I can't think of a good way to chose the subdivision t so that > >> this method is as good as the rotation and make monotonic one > (nothing > >> with any properties I can pro
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Are quarter circles easy to detect? Their 2 angles should both be 45 degrees and their lengths should be similar (I don't think the middle control segment is the same length as the outer 2, but there is probably some tolerance where a single subdivision works fine). Either way, hopefully the performance is much better now that the dashing and widening code has to process a lot fewer segments. Is it? ...jim On 9/2/2010 7:08 AM, Denis Lila wrote: Hello Jim. Sorry for all the e-mails. I implemented the rotating version. The rotation introduces small numerical errors, so when I solve for the roots of dx/dt and dy/dt, the values of t I get are slightly off. So for a rotated quarter circle, what happens is that it gives me a root at, say, t=0.9996... so I still end up subdividing quarter circles. I "fixed" this by ignoring all roots outside of (0.001,0.999), instead of ignoring roots outside of (0,1) which is the ideal solution. I don't like hardcoding constants like this. Add to this the higher complexity of the rotation, and I'm tempted to say it might be better to just bite the bullet on rotated quarter circles and widen them using 2 curves per side. I had one question: what do you think of widening all curves using quadratic curves? Their great simplicity might make things safer. We can guarantee that none of the strange behaviour I've seen and described with cubic curves will arise (but we'd have to use more of them). Also, I've tested the current implementation with a few hundred random cubic paths, and everything looks good so far. Thanks, Denis. - "Denis Lila" wrote: Hello Jim. I think this would actually ensure that every resulting curve can be rotated to be made monotonic in both x and y (at least after inflections are eliminated), which means it's at least as good as what I have now. While that first statement is true, it unfortunately does not mean it's "at least as good as" breaking the curve into monotonic pieces. I implemented the angle checking method, and the problem is that for curves like (0,0),(1000,1),(-1000,1),(0,0) it is very bad. That's because I implemented it by subdividing at t=0.5, so the angles in the resulting curves' polygons are still wide. After enough subdivisions the polygons would have angles below 45, but that would defeat the point, since we're trying to minimize the number of output curves. I can't think of a good way to chose the subdivision t so that this method is as good as the rotation and make monotonic one (nothing with any properties I can prove, anyway), so I'll implement the rotating version, as much as I don't like it. At least it gives a good upper bound in the number of output curves. Regards, Denis. - "Denis Lila" wrote: Hello Jim. Thanks for taking the time to think about this. I implemented a few different offsetting schemes. On well behaved curves, my original "parallel first and last control vectors and go through B(0.5)" algorithm was by far the best. Theoretically it is also somewhat better justified than the others (some of which were like Apache Harmony's way - offsetting p2 and p3), since we're interpolating instead of just using some heuristic. It is also the only one I've encountered that widens quarter circles optimally, and it only needs one curve per side too (i.e. if we have to widen the path of a PathIterator of a circle with radius r, using width w, Pisces' output will be identical to the output of the PathIterators of 2 circles with radii r+w and r-w (perhaps not identical identical, since PathIterators can use doubles, and we only use floats in pisces, but... that's nitpicking)). As I've said before, the only 2 problems with it were that it was bad on high curvatures (but this was fixed by breaking down the curves into monotonic ones), and it was bad on curves like p.moveTo(0,0);p.curveTo(100,100,0,100,100,1). I thought the latter was fixable with the "d1/(d1+d2)" algorithm I suggested in my previous e-mail. I implemented it, and it turns out I was wrong. Then I came up with my own variation of that algorithm (the original one I used was from Don Lancaster's website) that did sort of work. But then I implemented your suggestion of splitting the curve at the inflection points as well as breaking it into monotonic pieces, and the problem was gone. I didn't even have to use the fancy variation of the "d1/(d1 + d2)" algorithm - just the plain old interpolation one worked (I should say that the fancy one is still probably better, but undetectably so, now that we break at inflection points and at xy direction changes, so the added complexity is probably not worth it). I've attached my latest Stroker.java, if you want to take a look at these algorithms (they're in computeOffsetWay1 (for the old interpolation) and computeOffsetWay3 (for the fancy version). There are 2 more, but these aren't as good, and one is just shameful). I didn't make a webrev because I still need t
[OpenJDK 2D-Dev] hg: jdk7/2d/langtools: 20 new changesets
Changeset: 112fcc00659d Author:cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/112fcc00659d Added tag jdk7-b105 for changeset aaecac256d39 ! .hgtags Changeset: 2c1c657f69a4 Author:cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/2c1c657f69a4 Added tag jdk7-b106 for changeset 112fcc00659d ! .hgtags Changeset: a408ebb8b3d4 Author:cl Date: 2010-08-26 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a408ebb8b3d4 Added tag jdk7-b107 for changeset 2c1c657f69a4 ! .hgtags Changeset: 0fe472f4a332 Author:mcimadamore Date: 2010-08-05 09:44 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/0fe472f4a332 6881115: javac permits nested anno w/o mandatory attrs => IncompleteAnnotationException Summary: default annotation value is not attributed Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/6881115/T6881115.java + test/tools/javac/annotations/6881115/T6881115.out Changeset: 237f3bd52242 Author:mcimadamore Date: 2010-08-05 09:45 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/237f3bd52242 6857948: Calling a constructor with a doubly bogus argument causes an internal error Summary: problem when constructor resolution returns an erroneous symbol Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/6857948/T6857948.java + test/tools/javac/6857948/T6857948.out Changeset: a2d8c7071f24 Author:mcimadamore Date: 2010-08-10 14:52 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a2d8c7071f24 6975275: diamond implementation needs some cleanup Summary: resolution issues during diamond inference should be reported through Resolve.logResolveError() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: ea1930f4b789 Author:mcimadamore Date: 2010-08-10 14:53 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/ea1930f4b789 6975231: Regression test for 6881115 is failing with compiler output not matching expected output Summary: missing symbols are collected in an HashSet which doesn't preserve ordering Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/annotations/6881115/T6881115.out + test/tools/javac/diags/examples/AnnotationMissingValues1.java Changeset: c04ae2714f52 Author:lana Date: 2010-08-12 19:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c04ae2714f52 Merge Changeset: 27bae58329d5 Author:mcimadamore Date: 2010-08-16 14:56 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/27bae58329d5 6976649: javac does not enforce required annotation elements in arrays Summary: type annotation should take advantage of recursive annotation checking Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out ! test/tools/javac/annotations/pos/TrailingComma.java Changeset: dc550520ed6f Author:mcimadamore Date: 2010-08-16 14:58 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/dc550520ed6f 6369605: Unconstrained type variables fails to include bounds Summary: unconstrained type-variables with recursive bounds are not inferred properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/InvalidInferredTypes.java + test/tools/javac/generics/inference/6369605/T6369605a.java + test/tools/javac/generics/inference/6369605/T6369605b.java ! test/tools/javac/generics/inference/6638712/T6638712a.out Changeset: a31c511db424 Author:jjg Date: 2010-08-16 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/a31c511db424 6976833: options included twice in Example SimpleCompiler Reviewed-by: darcy ! test/tools/javac/diags/Example.java Changeset: c655e0280bdc Author:mcimadamore Date: 2010-08-19 11:50 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/langtools/rev/c655e0280bdc 6886247: regression: javac crashes with an assertion error in Attr.java Summary: capture conversion does not work on nested types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/wildcards/6886247/T6886247_1.java + test/tools/javac/generics/wildcards/6886247/T6886247_2.java + test/tools/javac/generics/wildcards/6886247/T6886247_2.ou
[OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 45 new changesets
Changeset: 9ad95be9deae Author:cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9ad95be9deae Added tag jdk7-b105 for changeset 3b0abcb51280 ! .hgtags Changeset: f8bbf376595c Author:yhuang Date: 2010-08-11 02:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/f8bbf376595c 6959252: convert the anonymous arrays to named arrays in Java List Resource files Reviewed-by: katakai, psun ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/sun/applet/resources/MsgAppletViewer.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java Changeset: 413cede85120 Author:yhuang Date: 2010-08-13 01:09 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/413cede85120 Merge - test/java/net/Socket/AccurateTimeout.java Changeset: b91ef6b60f4e Author:cl Date: 2010-08-16 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b91ef6b60f4e Merge Changeset: 882103f334bb Author:cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/882103f334bb Added tag jdk7-b106 for changeset b91ef6b60f4e ! .hgtags Changeset: 17a5d84b7561 Author:cl Date: 2010-08-26 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/17a5d84b7561 Added tag jdk7-b107 for changeset 882103f334bb ! .hgtags Changeset: 654145d6560a Author:lana Date: 2010-08-23 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/654145d6560a Merge - src/share/classes/sun/java2d/pisces/PiscesMath.java - src/share/classes/sun/java2d/pisces/Transform4.java Changeset: d0e314d59f84 Author:malenkov Date: 2010-08-10 19:29 +0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/d0e314d59f84 6960267: JTable.getRowHeight() returns value different from the specified default (16.0) with GTK L&F Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java Changeset: 58626b4eedcb Author:lana Date: 2010-08-12 11:23 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/58626b4eedcb Merge - test/java/net/Socket/AccurateTimeout.java Changeset: 23f72ec0d8e8 Author:peytoia Date: 2010-08-23 14:14 +0900 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/23f72ec0d8e8 6977550: (tz) Support tzdata2010l Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: a18a82d2d506 Author:lana Date: 2010-08-23 19:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a18a82d2d506 Merge Changeset: 367b90ed38b1 Author:chegar Date: 2010-08-03 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/367b90ed38b1 6973030: NTLM proxy authentication fails with https Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java Changeset: a21c46dac6cf Author:mullan Date: 2010-08-03 09:39 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/a21c46dac6cf 6653372: Error in java.security.KeyStore example code Reviewed-by: weijun ! src/share/classes/java/security/KeyStore.java Changeset: 2feeefb45a44 Author:mullan Date: 2010-08-03 09:55 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/2feeefb45a44 Merge Changeset: 3b63e506b57e Author:martin Date: 2010-08-03 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/3b63e506b57e 6955504: (str) String[Builder/Buffer].append(char[],int,int) throws OutOfMemoryError in b94 Summary: let arraycopy throw AIOOBE for invalid negative length Reviewed-by: chegar, forax ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 188f156148ea Author:apangin Date: 2010-08-04 20:25 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/188f156148ea 6945961: SIGSEGV in memcpy() during class loading on linux-i586 Summary: Check the result of strchr() in Bytecode Verifier Reviewed-by: kamg, acorn !
[OpenJDK 2D-Dev] hg: jdk7/2d/jaxp: 3 new changesets
Changeset: 5ba8469212a6 Author:cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/5ba8469212a6 Added tag jdk7-b105 for changeset 3233b9a4c12e ! .hgtags Changeset: 20ee37c1372a Author:cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/20ee37c1372a Added tag jdk7-b106 for changeset 5ba8469212a6 ! .hgtags Changeset: 7d379f8934ca Author:cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxp/rev/7d379f8934ca Added tag jdk7-b107 for changeset 20ee37c1372a ! .hgtags
[OpenJDK 2D-Dev] hg: jdk7/2d/jaxws: 3 new changesets
Changeset: bc45ccc5bcca Author:cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/bc45ccc5bcca Added tag jdk7-b105 for changeset 39eb4f3031f4 ! .hgtags Changeset: 017612ea6af4 Author:cl Date: 2010-08-19 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/017612ea6af4 Added tag jdk7-b106 for changeset bc45ccc5bcca ! .hgtags Changeset: b1ca39340238 Author:cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/jaxws/rev/b1ca39340238 Added tag jdk7-b107 for changeset 017612ea6af4 ! .hgtags
[OpenJDK 2D-Dev] hg: jdk7/2d/hotspot: 65 new changesets
Changeset: 3dc64719cf18 Author:cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3dc64719cf18 Added tag jdk7-b105 for changeset 6709c14587c2 ! .hgtags Changeset: a81afd9c293c Author:alanb Date: 2010-07-16 13:14 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a81afd9c293c 6649594: Intermittent IOExceptions during dynamic attach on linux and solaris Reviewed-by: dcubed, dholmes ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 920aa833fd16 Author:apangin Date: 2010-07-17 21:49 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/920aa833fd16 Merge Changeset: a5c9d63a187d Author:apangin Date: 2010-07-20 08:41 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a5c9d63a187d 6964170: Verifier crashes Summary: Check if klassOop != NULL rather than klass_part != NULL Reviewed-by: kamg, never ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verifier.cpp Changeset: 7f0fdccac34f Author:apangin Date: 2010-07-25 07:31 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/7f0fdccac34f Merge ! src/share/vm/classfile/verifier.cpp Changeset: 3d90023429ec Author:aph Date: 2010-07-28 17:38 +0100 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/3d90023429ec 6888526: Linux getCurrentThreadCpuTime is drastically slower than Windows Reviewed-by: dcubed, dholmes ! src/os/linux/vm/globals_linux.hpp ! src/share/vm/runtime/arguments.cpp Changeset: a64438a2b7e8 Author:coleenp Date: 2010-07-28 17:57 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/a64438a2b7e8 6958465: Sparc aten build24.0: openjdk-7.ea-b96 failed Error: Formal argument ... requires an lvalue Summary: Fix compilation errors. Made non-const references const so can be assigned with lvalue. Reviewed-by: phh, xlu ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp Changeset: 126ea7725993 Author:bobv Date: 2010-08-03 08:13 -0400 URL: http://hg.openjdk.java.net/jdk7/2d/hotspot/rev/126ea7725993 6953477: Increase portability and flexibility of building Hotspot Summary: A collection of portability improvements including shared code support for PPC, ARM platforms, software floating point, cross compilation support and improvements in error crash detail. Reviewed-by: phh, never, coleenp, dholmes ! agent/src/os/linux/ps_proc.c ! make/Makefile ! make/defs.make ! make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/product.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/javaFrameAnchor_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/linux/launcher/java_md.c ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpre
[OpenJDK 2D-Dev] hg: jdk7/2d/corba: 3 new changesets
Changeset: 519daea4 Author:cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/519daea4 Added tag jdk7-b105 for changeset 6f21b030092f ! .hgtags Changeset: 232adb83eae8 Author:cl Date: 2010-08-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/232adb83eae8 Added tag jdk7-b106 for changeset 519daea4 ! .hgtags Changeset: 8d810527b499 Author:cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/corba/rev/8d810527b499 Added tag jdk7-b107 for changeset 232adb83eae8 ! .hgtags
[OpenJDK 2D-Dev] hg: jdk7/2d: 3 new changesets
Changeset: 43096cccf1ce Author:cl Date: 2010-08-13 11:38 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/43096cccf1ce Added tag jdk7-b105 for changeset 9f96a4269d77 ! .hgtags Changeset: 7d396ad455c3 Author:cl Date: 2010-08-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/7d396ad455c3 Added tag jdk7-b106 for changeset 43096cccf1ce ! .hgtags Changeset: 140fdef4ddf5 Author:cl Date: 2010-08-26 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/2d/rev/140fdef4ddf5 Added tag jdk7-b107 for changeset 7d396ad455c3 ! .hgtags
[OpenJDK 2D-Dev] fix for 6697721 is incomplete
Hi,
I recently ran into a problem with using fractional font metrics with
OpenJDK. The attached code (FractionalTextMetricsBug.java) reproduces
the problem and the attached image shows the result on OpenJDK6 (which
is the same as the result on OpenJDK7).
I believe this problem was introduced with the fix for 6697721 [1] as I
observed this behaviour with OpenJDK6 after that particular fix was
backported. The value of advh is based on ftglyph->linearHoriAdvance,
which is the advance for the unhinted glyph [2]. If the glyph is hinted
(which is often the case), ftglyph->metrics.horiAdvance gives a better
value.
The attached patch is one attempt at fixing the problem. I am not sure
if TEXT_AA_OFF (the antialiasing mode) is related to hinting - even
though the comments in freetypescaler say that it is. With the patch, my
test case works, and the text is rendered correctly with antialising set
to either VALUE_TEXT_ANTIALIAS_ON, VALUE_TEXT_ANTIALIAS_OFF or
VALUE_TEXT_ANTIALIAS_LCD_HRGB.
Thanks,
Omair
[1] http://hg.openjdk.java.net/jdk7/2d/jdk/rev/4092c04aeae7
[2]
http://freetype.sourceforge.net/freetype2/docs/reference/ft2-base_interface.html#FT_GlyphSlotRec
<>import java.awt.Canvas;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.RenderingHints;
import javax.swing.JFrame;
import javax.swing.SwingUtilities;
import javax.swing.UIManager;
public class FractionalTextMetricsBug {
public static void main(String[] args) throws Exception {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
JFrame frame = new JFrame("Anti aliasing rendering test");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Canvas drawingArea = new Canvas() {
/**
*
*/
private static final long serialVersionUID =
-2281399219700950363L;
@Override
public void paint(Graphics _g) {
Graphics2D g = (Graphics2D) _g;
g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
RenderingHints.VALUE_TEXT_ANTIALIAS_ON);
g.setRenderingHint(RenderingHints.KEY_FRACTIONALMETRICS,
RenderingHints.VALUE_FRACTIONALMETRICS_ON);
g.drawString("Graphics2D Rendered Text", 5, 15);
}
};
drawingArea.setSize(new Dimension(300, 50));
frame.getContentPane().add(drawingArea);
frame.pack();
frame.setVisible(true);
}
});
}
}
diff -r 882103f334bb src/share/native/sun/font/freetypeScaler.c
--- a/src/share/native/sun/font/freetypeScaler.c Thu Aug 19 15:13:12 2010 -0700
+++ b/src/share/native/sun/font/freetypeScaler.c Tue Aug 31 14:15:57 2010 -0400
@@ -797,7 +797,12 @@
}
if (context->fmType == TEXT_FM_ON) {
-double advh = FTFixedToFloat(ftglyph->linearHoriAdvance);
+double advh;
+if (context->aaType == TEXT_AA_OFF) {
+advh = FTFixedToFloat(ftglyph->linearHoriAdvance);
+} else {
+advh = FT26Dot6ToFloat(ftglyph->metrics.horiAdvance);
+}
glyphInfo->advanceX =
(float) (advh * FTFixedToFloat(context->transform.xx));
glyphInfo->advanceY =
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Hello Jim. Sorry for all the e-mails. I implemented the rotating version. The rotation introduces small numerical errors, so when I solve for the roots of dx/dt and dy/dt, the values of t I get are slightly off. So for a rotated quarter circle, what happens is that it gives me a root at, say, t=0.9996... so I still end up subdividing quarter circles. I "fixed" this by ignoring all roots outside of (0.001,0.999), instead of ignoring roots outside of (0,1) which is the ideal solution. I don't like hardcoding constants like this. Add to this the higher complexity of the rotation, and I'm tempted to say it might be better to just bite the bullet on rotated quarter circles and widen them using 2 curves per side. I had one question: what do you think of widening all curves using quadratic curves? Their great simplicity might make things safer. We can guarantee that none of the strange behaviour I've seen and described with cubic curves will arise (but we'd have to use more of them). Also, I've tested the current implementation with a few hundred random cubic paths, and everything looks good so far. Thanks, Denis. - "Denis Lila" wrote: > Hello Jim. > > > I think this would actually ensure that every resulting curve can > > be rotated to be made monotonic in both x and y (at least after > > inflections are eliminated), which means it's at least as good as > > what I have now. > > While that first statement is true, it unfortunately does not mean > it's > "at least as good as" breaking the curve into monotonic pieces. I > implemented the angle checking method, and the problem is that for > curves like (0,0),(1000,1),(-1000,1),(0,0) it is very bad. That's > because I implemented it by subdividing at t=0.5, so the angles > in the resulting curves' polygons are still wide. After enough > subdivisions the polygons would have angles below 45, but that would > defeat the point, since we're trying to minimize the number of output > curves. > I can't think of a good way to chose the subdivision t so that > this method is as good as the rotation and make monotonic one (nothing > with any properties I can prove, anyway), so I'll implement the > rotating version, as much as I don't like it. At least it gives a good > upper bound in the number of output curves. > > Regards, > Denis. > > - "Denis Lila" wrote: > > > Hello Jim. > > Thanks for taking the time to think about this. > > > > I implemented a few different offsetting schemes. On well behaved > > curves, my original "parallel first and last control vectors and go > > through B(0.5)" algorithm was by far the best. Theoretically it is > > also somewhat better justified than the others (some of which were > > like Apache Harmony's way - offsetting p2 and p3), since we're > > interpolating instead of just using some heuristic. It is also > > the only one I've encountered that widens quarter circles optimally, > > and it only needs one curve per side too (i.e. if we have to widen > > the path of a PathIterator of a circle with radius r, using width w, > > Pisces' output will be identical to the output of the PathIterators > > of 2 circles with radii r+w and r-w (perhaps not identical > identical, > > since PathIterators can use doubles, and we only use floats in > pisces, > > but... that's nitpicking)). > > > > As I've said before, the only 2 problems with it were that it was > bad > > on high curvatures (but this was fixed by breaking down the curves > > into > > monotonic ones), and it was bad on curves like > > p.moveTo(0,0);p.curveTo(100,100,0,100,100,1). I thought the latter > was > > fixable with the "d1/(d1+d2)" algorithm I suggested in my previous > > e-mail. > > I implemented it, and it turns out I was wrong. Then I came up with > my > > own > > variation of that algorithm (the original one I used was from Don > > Lancaster's > > website) that did sort of work. But then I implemented your > suggestion > > of > > splitting the curve at the inflection points as well as breaking it > > into > > monotonic pieces, and the problem was gone. I didn't even have to > use > > the > > fancy variation of the "d1/(d1 + d2)" algorithm - just the plain old > > interpolation one worked (I should say that the fancy one is still > > probably > > better, but undetectably so, now that we break at inflection points > > and at > > xy direction changes, so the added complexity is probably not worth > > it). > > > > I've attached my latest Stroker.java, if you want to take a look at > > these > > algorithms (they're in computeOffsetWay1 (for the old interpolation) > > and > > computeOffsetWay3 (for the fancy version). There are 2 more, but > these > > aren't as good, and one is just shameful). I didn't make a webrev > > because > > I still need to fix how it handles cusps (which should be easy), and > I > > need to implement a way to avoid subdividing a rotated quarter > circle. > > I can do this either by rotating curves so that p2-p1 is parallel to > > the > > x axis
