| Summary: | scrolling in okular is slow when thumbnails are enabled in navigations panel | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Martin Stolpe <martinstolpe> | ||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | ||||||
| Version: | 7.5 (2009.10) | ||||||
| Hardware: | Other | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Martin Stolpe
2010-05-05 07:43:47 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. 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. (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. > 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 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.