Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Actually, I just finished implementing a solution to the problem I've been talking about. I've only tested it on the problematic curve I have talked about, but it works very well. I've also changed the structure of the engine quite a bit. Mostly to optimize things and get rid of unnecessary object allocations, but also to clean things up a bit - the way it was, with nearly all the logic for widening and dashing in BezCurve.java wasn't very pleasing and it couldn't be made so unless we made the class completely immutable and threw performance out the window. It doesn't look like I'll be able to send a webrev out by today, but I'll work on it a bit during the weekend and I should have a good one by Monday. Regards, Denis. - "Jim Graham" wrote: > Hi Denis, > > Things got really busy for me over the past week so I wasn't able to > keep up with the discussion on this, but I will be looking more at it > > next week. In the meantime it sounds like you are on the right track. > > I wish I'd have investigated it to the level you are at so I could be > of > more immediate help, but hopefully I'll get there when I review your > various changes... > > ...jim > > On 9/7/2010 2:11 PM, Denis Lila wrote: > >> Hello Jim. > >> > >> So, I finally have a webrev for serious consideration: > >> http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ > >> There are still some printing statements I used for debugging, and > >> the whitespace is probably pretty bad (tell me if this poses a > problem > >> when reading the code, and I'll clean it up), but I don't want to > >> waste time removing that stuff unless necessary, since this is > >> doubtlessly not the last version. I also included a Test.java > >> file that I found useful for testing and debugging. It has a main > >> method, and it allows pisces to run as a standalong project in > >> eclipse (as long as you set the JRE to be openjdk7 since it needs > >> to know about AATileGenerator and some other non public > interfaces). > >> > >> From testing it, the only problem I noticed is that it doesn't do > >> very well with tight loops. So, a path like > >> p.moveTo(0,0);p.curveTo(1000, 1000, 400, 500, 0, -150); > >> isn't stroked very well when using the rotating algorithm. When > using > >> just the "make monotonic" algorithm it is ok (right now, it is set > to > >> use the latter - you can change this by uncommenting > Stroker.java:1011 > >> and commenting out Stroker.java:1012). This leads me to believe > that > >> we need to detect and perhaps subdivide at loops in addition to > the > >> current subdivision locations. However, I have not yet looked too > deeply > >> into why the problem arises and how to fix it. I welcome > suggestions. > >> > >> Thanks, > >> Denis. > > > > I figured out what the problem is. The problem isn't really tight > loops. > > The problem is cusps in the offset curves. These happen when the > line width > > is equal to the radius of curvature of the curve being processed > (although, > > this may be just a necessary condition and not sufficient, but this > doesn't > > matter). > > > > It seems like we have to split at values of t where the above > condition > > holds. However, I can't see a way to do this without resorting to > Newton's method > > for finding the roots of RadiusOfCurvature(t) - lineWidth. It would > be > > really easy, however, if we had the arc length parametrization of > the curve > > in question, but this won't necessarily be a polynomial. A good way > might be > > to find a polynomial approximation to its inverse (this would make > dashing considerably > > easier too). > > > > Regards, > > Denis. > > > > - "Denis Lila" wrote: > > > > > >> > >> - "Jim Graham" wrote: > >> > >>> 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 cod
Re: [OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
Hi Denis, Things got really busy for me over the past week so I wasn't able to keep up with the discussion on this, but I will be looking more at it next week. In the meantime it sounds like you are on the right track. I wish I'd have investigated it to the level you are at so I could be of more immediate help, but hopefully I'll get there when I review your various changes... ...jim On 9/7/2010 2:11 PM, Denis Lila wrote: Hello Jim. So, I finally have a webrev for serious consideration: http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/ There are still some printing statements I used for debugging, and the whitespace is probably pretty bad (tell me if this poses a problem when reading the code, and I'll clean it up), but I don't want to waste time removing that stuff unless necessary, since this is doubtlessly not the last version. I also included a Test.java file that I found useful for testing and debugging. It has a main method, and it allows pisces to run as a standalong project in eclipse (as long as you set the JRE to be openjdk7 since it needs to know about AATileGenerator and some other non public interfaces). From testing it, the only problem I noticed is that it doesn't do very well with tight loops. So, a path like p.moveTo(0,0);p.curveTo(1000, 1000, 400, 500, 0, -150); isn't stroked very well when using the rotating algorithm. When using just the "make monotonic" algorithm it is ok (right now, it is set to use the latter - you can change this by uncommenting Stroker.java:1011 and commenting out Stroker.java:1012). This leads me to believe that we need to detect and perhaps subdivide at loops in addition to the current subdivision locations. However, I have not yet looked too deeply into why the problem arises and how to fix it. I welcome suggestions. Thanks, Denis. I figured out what the problem is. The problem isn't really tight loops. The problem is cusps in the offset curves. These happen when the line width is equal to the radius of curvature of the curve being processed (although, this may be just a necessary condition and not sufficient, but this doesn't matter). It seems like we have to split at values of t where the above condition holds. However, I can't see a way to do this without resorting to Newton's method for finding the roots of RadiusOfCurvature(t) - lineWidth. It would be really easy, however, if we had the arc length parametrization of the curve in question, but this won't necessarily be a polynomial. A good way might be to find a polynomial approximation to its inverse (this would make dashing considerably easier too). Regards, Denis. - "Denis Lila" wrote: - "Jim Graham" wrote: 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 pi
[OpenJDK 2D-Dev] Please review change in regression test sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java
Hi, can anybody please review the simple change in regression test sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java? Webrev containing this change is available here: http://cr.openjdk.java.net/~ptisnovs/OnScreenRenderingResizeTest/ I replaced the call of a method Point.move() by Point.translate() because this test did not work correctly in those cases when the top (and probably left) screen area is occupied by a toolbar/panel (which is the default settings for GNOME for example). I've successfully tested this changed regression test on RHEL5 with GNOME installed (with and without top panel). Cheers Pavel T. PS: the name of the method Point.move() is a bit confusing for me as I (and probably also author of the test) have thought it is similar to Point.translate() ;-)
