[cairo-bugs] [Bug 43397] EXTEND_NONE is used instead of EXTEND_PAD when src sample area is entirely within the surface

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun Jan 22 09:09:06 PST 2012


https://bugs.freedesktop.org/show_bug.cgi?id=43397

--- Comment #30 from Bill Spitzak <spitzak at gmail.com> 2012-01-22 09:09:06 PST ---
I, and I believe everybody else arguing with you, FULLY understand exactly what
you are saying.

> No, that is not the issue. Cairo knows that EXTEND_PAD, EXTEND_NONE, anything have the same result. It is just guessing that the default will be fast. Unfortunately this is not the case for that specific driver, but might very well be in many other cases.

I can guarantee that EXTEND_NONE is the *SLOWEST* for any driver that uses a
modern GPU to sample the image, since there is no incentive to accelerate that
mode on the GPU hardware (for the simple reason that it is *useless* for
graphics due to double-multiplying of the edges of texture-mapped shapes).

In C code I have found that EXTEND_PAD is much easier to implement than
EXTEND_NONE, especially for correct antialiasing around the edges. Nuke
actually implements EXTEND_NONE by enlarging the image to add a zero pixel all
around the edge and then using EXTEND_PAD on this. Though this is due to Nuke
using more complex larger sampling filters that make EXTEND_NONE very difficult
to implement in other ways, since Cairo is limiting itself to very small
filters it may have other methods.

Thus I believe EXTEND_NONE is the slowest for *EVERY* driver other than the
XRender one!

> Can you guarantee that no driver will have regressions if it gets PAD instead
of NONE?

Yes. The driver must be able to correctly clip an EXTEND_PAD image that is
*partially* clipped, otherwise the driver is broken with current Cairo anyway.
I am willing to bet there is no driver that correctly implements partial-clip
of an EXTEND_PAD image that does not correctly render an image where all of the
extend is clipped.

> Optimizing the default case looks quite important, so I would definitely try to do that, instead of trying to avoid the default.

Yes, and as has been stated several times, there are three methods:

1. What we have now: Cairo wastes time on a clipping test to turn the mode to
EXTEND_NONE. The driver is then forced to *REPEAT* that test in order to detect
if this was the reason it got EXTEND_NONE, and change the mode to the fastest
one in this case.

2. (what everybody expected): Cairo leaves the extend mode alone and sends it
to the driver. If (and only if) the driver knows it could run faster with
another mode, the driver then runs the clipping test and changes to that other
mode. It can skip this test if the mode is already the fastest.

3. (the most common proposal here): Add EXTEND_ANY to the modes, modifying the
XRender API to accept it as well. Cairo still runs it's clipping test and
changes the mode to EXTEND_ANY. The driver can then change it to the fastest
mode without re-running the clipping test. This is not as fast as #2 because
the test is run even when the mode is already the fastest. However it is faster
than #1 because the test is only run once. It also means the driver writers do
not have to implement the test.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.


More information about the cairo-bugs mailing list