| Summary: | Single-pass black or white subpixel text | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Owen Taylor <otaylor> |
| Component: | Server/Acceleration/EXA | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | enhancement | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
The multipass method is, as it turns out, already there as exaTryMagicTwoPassCompositeHelper. (One problem with turning on logging of fallbacks in the driver is it's hard to tell whether, once the driver bounces an operation, if it goes to software or to something better...) So the main point of this bug is a more-or-less minor optimization of white and black text. Both of those optimizations could be done in the generic exa layer, and probably should, so I'm going to move the bug. The prerequisite may be more intelligent handling of solid colorsm both the legacy 1x1 surfaces and RenderCreateSolidFill. (Right now we don't accelerate pictures created by RenderCreateSolidFill at all!) This is as fixed as it's getting I think. |
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.
Just wanted to throw a couple of ideas down in writing for getting subpixel-anti-aliased text accelerated. Looking at: if (pMaskPicture->componentAlpha) { /* Check if it's component alpha that relies on a source alpha and * on the source value. We can only get one of those into the * single source value that we get to blend with. */ if (RadeonBlendOp[op].src_alpha && (RadeonBlendOp[op].blend_cntl & RADEON_SRC_BLEND_MASK) != RADEON_SRC_BLEND_GL_ZERO) { RADEON_FALLBACK(("Component alpha not supported with source " "alpha and source value blending.\n")); } } That makes sense: the blend function is being applied after whatever fanciness we do to compute the source value ... *but* almost all text that is drawn has very special source values ... it's either black or white. If we set the source value to be the mask, then a black source with PictOpOver is: src_factor=ZERO, dest_factor=ONE_MINUS_SRC_COLOR And a white source with PictOpOver is: src_factor=SRC_COLOR, dest_factor=ONE_MINUS_SRC_COLOR The second idea is that, unless I'm mistaken, we can do arbitrary colors with two passes: Do the first pass with the source color being the mask and: src_factor=ZERO, dest_factor=ONE_MINUS_SRC_COLOR And the second pass with the source value as the the source modulated with the mask and: src_factor=SRC_COLOR, dest_factor=GL_ONE To avoid weird visual effects you might want to only do the multipass rendering when rendering to a pixmap and not to the front buffer, but nobody in their right mind is rendering to the front buffer these days.