[Pixman] [PATCH] Don't discriminate PAD and REFLECT repeat in standard fast paths
siarhei.siamashka at gmail.com
Thu Sep 23 09:32:12 PDT 2010
It seems to me that you are looking at the problem from a bit different angle.
The whole issue is that the developers of radeon drivers are recommending
to use PAD repeat in applications in order to avoid some performance problems
on this type of hardware. But if the application developers listen to that and
start using PAD repeat more often, then software rendering done via pixman is
going to take a severe performance hit unless this minor issue is addressed.
Putting myself in application developer's shoes, I can imagine that deciding
whether to use PAD repeat may be non-obvious if there are cases (like the use
of pixman) where it causes performance regressions.
So let's just make PAD repeat fast in pixman in order not to hinder its
adoption anywhere else :)
The patch discussed here is not supposed to change pixman behavior in any way,
it's just a performance optimization.
On Wednesday 22 September 2010 21:03:34 Bill Spitzak wrote:
> What I do in OpenGL is draw a rectangle (well two triangles) textured
> with the image with PAD repeat. Outside the rectangle is 0,0,0,0. This
> produces the sharp edge I wanted and allows full acceleration to be
> used. Because OpenGL and DirectX assume that such sharp edges are how
> images will be drawn with translations, they obviously made this the
> accelerated path.
> Even if you don't want to use geometry, you could also intersect the
> clip with a quad (using the current clip implementation) and then draw
> all images with PAD.
> The problem is that you have to get rid of the current, and useless,
> definition of NONE. It must be changed to make a "sharp" edge. This will
> not change the output when the image scale is 1 or less, and I believe
> the change when the image scale is > 1 will produce the results desired
> by most users (ie they expect that drawing a 10x10 image will cover the
> same pixels as a 10x10 rectangle).
> Soeren Sandmann wrote:
> > Bill Spitzak <spitzak at gmail.com> writes:
> >> This is in fact what users expect, and also what other graphics
> >> libraries are doing (which explains why the hardware is supporting PAD
> >> directly).
> > The reason Render's NONE is difficult to accelerate in hardware is
> > that for formats without alpha (such as x8r8g8b8), Render wants the
> > border to be (0, 0, 0, 0), whereas GL will give you (0xFF, 0, 0, 0).
> > I thought I heard at one point that Direct3D can do (0, 0, 0, 0), but
> > maybe not.
> > Soren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Pixman