> Cool! Yeah fonts might be a little problem. As far as I understand from > the API docs, fonts are basically also rendered as shapes (a GlyphVector > returns shapes for each character). But how do we get the shapes into > the memory ..? I think Sascha's work might be a good start.
You *could* render fonts as shapes, but in general you don't want to do it the same way. Fonts need hinting and a different form of antialiasing to look good. (Perhaps you've some time run into a PS/PDF document where the text is rendered as shapes - seems to happen with latex docs a lot - in which case it tends to look like crap on the screen, but just fine once you print it.) Java2D has a seperate font-rendering engine, and GlyphVector is the final step in that, prior to rendering. > The third big problem will be images. But at the moment I don't want to > think too far. The problem that I will work on next is efficient filling > of (arbitrary) shapes. afaics, most java2d operations boil down to > filling shapes (either by calling fillXXX() or by calling drawXX(), > which will also end up filling a shape - the stroked shape. I found some > interesting articles on that: Images aren't so bad. You just draw it tiled over the whole area you want filled, and then use the outline shape as the clipping bounds. The clipping algorithm is more or less the same as for rendering the shapes, you work on a scanline basis. /Sven
