Phil Endecott wrote: > Some more thoughts about the large-font aspect of this: > > Phil Endecott wrote: >> I have been looking at FreeType and thinking about how I could improve >> DirectFB's use of it. In particular, I would like to be able to render >> rotated text (in multiples of 90 degrees) and to make rendering of >> large font sizes (hundreds or thousands of pixels) more efficient. > >> Regarding large fonts, it looks to me as if the DirectFB freetype code >> loops over each pixel in the glyph bitmap > > I now see that the code that I was looking at in idirectfbfont_ft2.c is > run only once after FreeType is called to copy the glyph bitmap into > DirectFB's font cache, from where it is eventually blitted to the > target. So the savings to be made are not so substantial. > > Unfortunately this does not scale well to very large fonts. (In my > application the user can zoom in as much as they like. Imagine a map > browser. When you are zoomed in to see a single street, a small part > of the name of the city may appear (semi-transparent?) in characters > much larger than the screen.) So a very large character will always be > rendered in full into the cache where it will use a great deal of > space. Ideally, only the portion that is actually needed would be stored. > > I think it would be a lot of work to adapt the cache to store partial > characters. So I think I will consider how I could implement a > separate function just for rendering very large font sizes.
A public API or a separate hook in the font module API? > I think that I can do this by getting spans from FreeType, rather than > a bitmap, and using DirectFB's FillSpans function to render them. It's > easy to clip the spans to only the visible region, and storing spans > would use much less memory than bitmaps (and it can be system rather > than video memory). A quick test suggests that performance using > FillSpans is OK. > > It looks as if FillSpans just calls FillRectangle. Is there any > hardware that directly supports FillSpans, or similar? The driver's FillRectangle() is called or each span at the moment, i.e. no FillSpans() driver hook, but there's only one EmitCommands() at the end, e.g. with the SH7722 driver there's one big display list submitted to the hardware. > One thing that I probably lose with this method is anti-aliasing, > unless I individually set the grey pixels at each end of each span > afterwards, somehow. I'm not sure if this is going to be an issue for > me. Ideally, FillSpans coordinates would be fractional. Anti aliased edges in the DirectFB rendering API would be good... -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
