Intel ( i845G ) profiling

Jose Gonzalez jose_ogp at juno.com
Wed Mar 19 06:55:24 PDT 2008


    Eric Anholt wrote:

 > Firefox is by far the best 2D desktop performance test we've
 > found so far (render microbenchmarks I've seen so far overvalue
 > image scaling and undervalue text rendering and trapezoid
 > rasterization).

    There seems to be some sort of odd confusion in the gfx
community here.. On one hand, one often sees the phrase "scalable
user interfaces" touted as some kind of holy-grail around which
gfx libs/apis should be designed, and yet on the other hand there
seems to be little emphasis on good, fast image transformations.
    One can only conclude that either these 'scalable guis'
are not meant to be all that scalable, or if they are they don't
work/look very well, or they must look like exagerated cartoons,
or be so incredibly complex as to be un-feasible for real-time use,
or..?

    Also, if trapezoids are to be used as the primary method
for rendering 'paths' or other geometric figures, so that xrender
aims to accelerate the rendering of such, one should also consider
the series of steps leading from such figures to the set of traps.
    This is not a trivial step in the gfx pipeline, and oddly
none of the common gfx libs I'm aware of that implement such figure
drawing seem to have a means by which such generated traps could
be re-used for rendering a given figure - I could be mistaken in
that, but many seem to simply destroy such data upon the completion
of a rendering call. At best then, one is forced to cache the
result of rendering such figures to a buffer and re-use that..
and hope that some things aren't changing a whole lot.

    In all, it appears there may be a kind of miss-match of
goals and ideals and the methods/libs/apis used to realize these.




More information about the xorg mailing list