Bug 27983 - scrolling in okular is slow when thumbnails are enabled in navigations panel
Summary: scrolling in okular is slow when thumbnails are enabled in navigations panel
Status: RESOLVED WORKSFORME
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.5 (2009.10)
Hardware: Other Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-05 07:43 UTC by Martin Stolpe
Modified: 2010-09-27 13:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
oprofile output (254.71 KB, application/x-gzip)
2010-05-05 07:43 UTC, Martin Stolpe
no flags Details

Description Martin Stolpe 2010-05-05 07:43:47 UTC
Created attachment 35431 [details]
oprofile output

Scrolling is really fast if the thumbnails panel is disabled.

Enabling "#define RADEON_TRACE_FALL 1" leads to the following output:
R300CheckComposite: Component alpha not supported with source alpha and source value blending.
R300CheckCompositeTexture: Unsupported picture format 0x1011000

Which is almost the same output as in bug #27954.
Comment 1 Michel Dänzer 2010-05-05 08:03:49 UTC
(In reply to comment #1)
> R300CheckComposite: Component alpha not supported with source alpha and source
> value blending.

This is probably related to sub-pixel anti-aliased text and harmless - EXA can still accelerate it in two passes.

> R300CheckCompositeTexture: Unsupported picture format 0x1011000

From the oprofile output it looks like this could be the problem: apparently the client uses sharp trapezoids, which cannot be accelerated at all yet. If it were to use smooth trapezoids instead, the trapezoids would still be rasterized in software but at least the composition step could be accelerated.
Comment 2 Clemens Eisserer 2010-05-11 15:38:32 UTC
Since nobody seems to be able to change the trapezoid rasterization code to emit sharp trapezoids on A8 masks, would it make sence to expand the resulting A1 mask to an A8 mask before composition?
Its not optimal, but way better whats happening for now.
Comment 3 Michel Dänzer 2010-05-12 03:13:25 UTC
(In reply to comment #2)
> Since nobody seems to be able to change the trapezoid rasterization code to
> emit sharp trapezoids on A8 masks,

What makes you think that 'nobody seems to be able to'?

> would it make sence to expand the resulting A1 mask to an A8 mask before
> composition?

That would indeed be another approach, which would also benefit non-trapezoid use of 1-bit masks.

In both cases I think lack of volunteers / time / interest is a bigger issue than lack of ability.
Comment 4 Clemens Eisserer 2010-05-12 05:29:32 UTC
> What makes you think that 'nobody seems to be able to'?
Tried to understand rasterizeEdge() for quite a while, but whatever question I had, nobody could come up with an answer.
I hope the planned introduction of RLE masks to RENDER will take away a bit of importance of this code.

> That would indeed be another approach, which would also benefit non-trapezoid
> use of 1-bit masks.
If only my C and X knowledge wouldn't be that bad. Hopefully I get a timeslot to do at least some things with X floating arround in my head ;)

Thanks again for your work, Clemens
Comment 5 Martin Stolpe 2010-09-27 13:08:31 UTC
Closing this bug because the default engine for qt will be switched to raster where the performance drop doesn't appear. It's also not a problem when using gallium with xorg state tracker and qt's native backend.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.