On Wed, 2006-07-12 at 17:09 -0400, Francis Kung wrote: > Hey, > > Attached is an updated patch to fix the alpha composite stroking bug. > > It works by drawing the stroked shape (using cairo's stroke function) on > a new surface, then using this surface as an alpha mask. Only the mask > and paint functions in cairo let us specify an alpha value. > > Currently (pre-patch), we attempt to stroke the ship ourselves before > passing it to cairo to paint, but this is buggy and also results in a > lot of JNI overhead. The masking solution avoids most of the JNI, at > the expense of creating a new cairo surface for each stroke-with-alpha > operation in native code (I can't find any way to clear or reset a > surface between operations). >
Um. I'm not sure I like this solution. Could you explain a bit more what the original problem was here? (using BasicStroke to stroke it and then filling the class). Was it just that BasicStroke is buggy? Is this latest solution that much faster? (Certainly it's more memory consuming.) My suggestions would be to either: 1) Complete BasicStroke (This must be done, sooner or later, preferably sooner) 2) Get Cairo to stroke with alpha. Either by: 2a) Implementing of the to-be-implemented cairo_stroke_to_path 2b) Implementing a new stroke_with_alpha function 3) Do a Cairo hack, e.g. take the cairo stroker code and use it for the time being until 1 or 2 is completed, which they will be sooner or later. 4) Implement general support for all Composites. Which would also fix alpha compositing since we have a working AlphaComposite implementation. Furthermore, there are some things here I really dislike. This code breaks the context/backend-independence of CairoGraphics by assuming it's drawing to a cairo surface and that it has pixel dimensions. That's no good. Context-specific stuff* goes into the context-specific subclasses. (*composited drawing with custom composites, is certainly going to be context-specific though. Following the design, this will mean adding another abstract method.) While stroking speed is an issue (you seem concerned about the JNI calls), another thing that's been on the table for a while is that strokes and outlines should be cached. First, all awt.geom objects should cache their PathIterators. (not all do) Second, since PathIterator objects are immutable we can easily cache the corresponding cairo_path_t objects. That should probably be significantly faster for all stroked shapes and all but the simplest filled paths. /Sven
