Intel ( i845G ) profiling

[Eric Anholt]

On Wed, 2008-03-19 at 09:55 -0400, Jose Gonzalez wrote:
> 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.

Every profile I've seen for "scalable UI" kind of stuff has trapezoid
rasterization at the top, and preparing the list of traps way down below
it.  But maybe you have profiles showing otherwise?

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080319/3f69e4ad/attachment.pgp>