> 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.)
BasicStroke wasn't working, but it also didn't seem to make much sense doing it this way when Cairo is capable of stroking for us (for the BasicStroke case, at least). Regular non-composite stroking is done directly by cairo, so it felt more consistent to do all BasicStroke stroking this way. I don't know how much faster this would be (need to fix BasicStroke before comparing), but I agree the memory usage isn't nice; this was essentially a temporary fix waiting for cairo_stroke_to_path. > My suggestions would be to either: > 1) Complete BasicStroke (This must be done, sooner or later, preferably > sooner) In order to remain consistent, though, the stroked shape should be visibly identical to cairo's stroking (hence why I had hoped to just have cairo do it instead of duplicating their code). It just feels like we should either always use BasicStroke, or we should always use cairo, but not both to create the stroked shape. > 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 This would be the ideal solution, I think, but that would tie Classpath to a development version of cairo... until the function is included in a cairo release, I don't think we can use it in classpath (please correct me if I'm wrong, though!) > 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. hmm... didn't even think of that one. Sounds like the cleanest option, actually, to get the general case working and then specifically optimize Alpha composites later. > 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.) Ahh, I didn't realise some surfaces used different dimension units. I thought I was safe using cairo_surface_create_similar(), but that's certainly a problem. > 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. Right. Makes sense once BasicStroke.getStrokedShape is working. Thanks, Francis
