Bug 15372

Summary: Single-pass black or white subpixel text
Product: xorg Reporter: Owen Taylor <otaylor>
Component: Server/Acceleration/EXAAssignee: 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:

Description Owen Taylor 2008-04-05 18:25:26 UTC
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.
Comment 1 Owen Taylor 2008-04-05 21:12:48 UTC
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!)

Comment 2 Adam Jackson 2018-06-11 19:50:42 UTC
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.