Sascha Brawer <[EMAIL PROTECTED]> writes: > (1) In GdkGraphics2D.walkPath(PathIterator), the treatment of quadratic > splines is almost, but not entirely correct. The page > > http://pfaedit.sourceforge.net/bezier.html
great! you know, I actually did dig through pfaedit's source code, but was too thick-headed to realize clearly what I was seeing. I have now made this change. > (2) Strokes that are not a BasicStroke: The drawing methods could > check whether the value of the stroke field is an instance of > BasicStroke. If not, they would not directly call into Cairo. For > example, GdkGraphics2D.draw(Shape) could look as follows: hm, yes, this is plausible. I will make this change too. > To increase performance, you could check whether the image is in a > format that is directly supported by Cairo, such as TYPE_INT_ARGB > with an sRGB ColorSpace. If this is the case, you could retrieve the > underlying DataBufferInt (via getRaster().getDataBuffer()) and > directly pass its int[] to GdkGraphics2D.drawPixels. ok, easy enough. > (4) Methods like GdkGraphics2D.drawRenderedImage can be implemented > by fetching a Raster from the RenderedImage and proceeding as with > BufferedImage. My proposal would be to define a private drawRaster > method that gets called by the various public image drawing methods. ok. > (5) It might be worth extending the native method > GdkGraphics2D.drawPixels to include an offset into the int[]. This > might be useful for cases where pixel (0,0) is not at index 0 of the > int[] that belongs to the DataBuffer. ok. > (6) You could further avoid copying pixel data by slightly changing > the native implementation of GdkGraphics2D.drawPixels. Instead of > GetIntArrayElements, I'd recommend using GetPrimitiveArrayCritical > and ReleasePrimitiveArrayCritical. See > > http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni- > 12.html#GetPrimitiveArrayCritical I would prefer not to do this for now. I can't say for certain that cairo won't make system calls that other java threads are aware of or possibly involved in. cairo *does* produce outgoing X traffic, possibly some traffic which will interact with the traffic the GDK peer threads are generating / receiving. > (7) As of how to implement Font.getFamily(java.util.Locale) etc., > (you have FIXMEs in that code) actually the FIXME is from previous authors. I have subsequently implemented the font model as described by the JDK documentation (property maps, logical, family and face name, etc.) and this is no longer a problem. > Maybe we can use an extended version of this interface for the > FontPeers that you've proposed in your recent e-mail. (The > getGlyphName method is not needed for Java2D, but it would be > necessary if someone wanted to write a decent PostScript or PDF > provider for javax.print.) yes, that interface looks like about all I need to support the pango font backend. perhaps a couple more methods, if I find any. shall I modify Font to use such a delegate, and place factory methods in Toolkit? (and shall we settle on the word "delegate" to denote peer-like things which our extended factory methods will produce?) -graydon _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
