Intel ( i845G ) profiling

[Jose Gonzalez]

Eric Anholt wrote:
> 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?
>
>   
    The issue I was alluding to here is more related to profiling
the complete rendering pipeline for such figure rendering - which
of course will vary depending on the method used to do the drawing
of the figure with xrender.
    And that's something that, if done via methods that eventually
emit trapezoids for rendering, will also depend on the way such traps
are generated from the figure and moved/rendered on the server.
    This kind of thing can be broken up in many ways, even if we
assume a fixed method for the generating of traps of a given fixed
figure on a given fixed system.
    In any case, it's not enough to go by profiles that assume
a fixed method of going from paths to a means of generating traps to
the traps rasterization on some system.. it may well be that traps
rasterization will usually dominate, or not - much could depend on
where/how things end up.
    But that's just not an exhaustive analysis of the overall
situation - it's too constrained to begin with, even if it may be
the accepted approach with xrender right now.

    And it's more that which leads to me think that there may
be a kind of miss-match of goals and ideals and the methods/libs/apis
used to realize these.