On 3/31/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Mike Emmel wrote: > > I can tell you it will probably be the same. > > What? Pango+Gdk+DirectFB consume much more CPU than only DirectFB > with a simple text layout. > > > If you need high performance text rendering then pango is not what you > > should be using. > > AFAIK Pango from the old days, that's true. > Its not much better now and its really because of the way pango is used. You really need to program it directly and save or cache as much of the data structures as possible or stack allocate. But unless you save the layout info its still reflowing the text on each call.
> > I've written a small library based on libxft called demontic that is > > the beginings of a simple text rendering library for cairo. I don't > > think you will see any real speed up using directfb libraries directly > > since both cairo and directfb simply call into freetype and render the > > resulting glyph directly. The only difference would be if the directfb > > blit is accelerated and the one used by cairo is not. If this is the > > case then its a bug in the cairo implementation and should be fixed. > > I'm not saying its perfect now since i've not verified the cairo blit > > paths and caching but there should be no difference between cairo and > > using the directfb freetype bindings if/when the cairo font > > implementation is correct. > > The core font rendering of DirectFB is faster than using Blit(), because > it's looping internally through all the characters and does the internal > driver calls directly. But you can use BatchBlit() which should catch up > with the core quite well. > > I'm not sure what you mean with "both cairo and directfb simply call > into freetype". DirectFB does that only once for each glyph and caches > the result, from then on just blits the corresponding cache location. > Right they should be the same its not right now I've not fully interfaced the cairo font api with DirectFB but as you say with the batch blit there should be basically no difference. Cairo will hand off basic text rendering to the underlying platform. Right now I'm using the cairo freetype backend which is basically the same as the one in DirectFB except that at the moment its probably using Cairo software blit pipeline not the dfb one. It should go directly to DFB if its a simple blit and only back through cairo for complex cases. Also I need to fall to rendering from a outline for very large font sizes and under some affine transforms but thats a different issue. In any case the overhead of cairo in the simple case should be just the check to see if it is the simple case then right into the DFB text pipeline. Ohh and one reason its the way it is right now is I need to save of the metrics in Cairo format so I need the cache up in cairo or we need to add a way to attach info to a char in DirectFB when it is cached some sort of userdata field maybe I've not worked through that. It would be nice to unify the font cache for everyone that wants to blit but to do that I think we need to be able to deal with and extensible data struct. Otherwise its the BatchBlit you mentioned. But I run into the same problem with WebKit and agian I need the font metrics in a application specific format so its worth thinking about. Mike > -- > 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
