Hi On 7/16/06, Matthew Allum <[EMAIL PROTECTED]> wrote: > Hi; > > On Sat, 2006-07-15 at 18:14 -0700, Carl Worth wrote: > > > > > > Carl, what are your thoughts on this ? > > > > I haven't looked closely at the issue yet. > > > > Please spend some time checking Jorn's posts + profiles, hopefully they > clearly show the issue with floating point causing slowdown in the font > rendering case at least ( on ARM ). > > > But my general take on this is that we are not ready to put new API > > into cairo for "performance reasons only" since we haven't > > sufficiently tried to optimize the implementation of the existing API > > yet. > > > > What do you see as downsides in extending API like this ? Would it even > be that bigger addition ? > > Id be interested your thoughts on optimising FP to perform when you dont > have an FPU. Maybe the amount of FP calls in pango-cairo could simply be > heavily reduced ? > > If Cairo cares about performing well on embedded type hardware ( maybe > it doesn't? ), use of fixed point seems pretty much mandatory on lower > end hardware - For example OpenGL ES, Playstation and Nintendo Handheld > graphics API's all use it.
I think many embedded folks like myself are in a very serious bind because I need pango and Gtk's evolving features But more importantly I need pango-cairo to be fast. It can be a double whammy because there are aspects outside of pango-cairo that I need in Gtk+ 2.8. So do I maintain massive patches to pango-cairo and Gtk+ 2.8-cairo stripping out floating point? Plus then do I fork cairo's api to add fix point? These are tough questions because, honestly the landscape is like a mine field. Sean > > Many thanks; > > -- Matthew > > > > > > > > _______________________________________________ > Performance-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/performance-list > _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
