Jordan Crouse wrote:
>> Unfortunately without a working callgraph it's not very clear to me what's
>> happening in amd_drv. At 24bpp gp_wait_until_idle() takes twice the time...
>
> What can we do to fix this? I would really like to know who is calling
> gp_wait_until_idle().
The problem seems
I've done some more profiling on the 16 vs. 24 bpp issue.
This time I used this test:
https://dev.laptop.org/git?p=sugar;a=blob;f=tests/graphics/hipposcalability.py
A simple speed test: I measured the time required to scroll down and up
one time all the generated list. Not extremely accurate, but
Bernardo Innocenti wrote:
> Aleph, could you post an oprofile of Sugar switching between zoom levels
> in both 16bpp and 24bpp? Doing it manually by pressing F1 to F4 would be
> good enough for me: I just want to get an idea of where we spend the time.
> Of course, X, amd_drv, pixman and cairo nee
Jim Gettys wrote:
> I'm worried about the fact that Cairo likes to do things 32 bits
> and they then have to be converted and composited at 16 bits;
Here are results of two runs of the cairo's performance test suite, at 16 and
24 bpp. Test hardware is a B4, xserver-1.4-branch, cairo 1.4.10. This
Bernardo Innocenti wrote:
> Performance of 16bpp VS 24bpp has been a hot topic recently.
> We know 24bpp to be much faster for some operations (my
> bench.py notably) and much slower for others (image puts),
> but it's not clear which one is the overall winner
> for our typical workload.
>
> Jim w
Bernardo Innocenti wrote:
> This patch is likely to make a big difference in the EXA codepath
> I benchmarked, which is heavily used by the OLPC GTK theme.
>
> The mini-benchmark attached to #1837 mimics it by drawing rounded
> edges shapes with Cairo.
> [...]
> Original Message
