[PATCH] Bug #25136: Revert "Fix clipping when windows are used as sources"

[Keith Packard]

On 27 Nov 2009 12:33:24 +0100, Soeren Sandmann <sandmann at daimi.au.dk> wrote:

> (a) The window can be partically offscreen and partially covered by
>     other windows, which means the set of pixels in it that can be
>     legally accessed is a possibly complex region, not just a
>     rectangle.

The only question is what color we provide for pixels not within the
window.

According to the spec, we're supposed to make them all be
0,0,0,0. Copying from an RGB to an ARGB pixmap is the only way to make
this work according to the spec; making this efficient would involve
computing the bounding box of the source as projected back through the
transform (which isn't all that hard; we've got a transform function
that computes the correct box).

However, I'd have to say that applications doing Render operations from
partially obscured windows pretty much deserve whatever we provide for
them; I'd bet they mostly don't care if we follow the spec (given that
we never have).  The cheapest pixel values we can provide are those
already present in whatever pixmap the source drawable is part of;
clipping to the bounds of that pixmap will keep applications from
crashing and do "something" similar to what they've always gotten. In
particular, I'd bet they'd be happier with this than the current
performance surprise.

> (d) We cannot completely ignore source clipping because there are
>     applications that make use of it.

Are they using source clipping and transforms together? That's the hard
case as we cannot simply convert one clipped operation into a sequence
of smaller unclipped ones.

>    How do you use this window as a source, producing correct results
>    while not reading outside the screen boundaries?

I'd say the first issue is to ensure that we don't read outside of the
screen boundaries, and that seems pretty easy; just clip the source
reading operations to the size of the screen, a single rectangle which
should be supported by hardware pretty easily.

Getting better results for clipped pixels is a secondary issue.

> Copying the window to a temporary pixmap is simple and gets the right
> answer in all cases, except that making accelerated callbacks from
> within fb doesn't work, and that software copying is too slow for
> large windows.

Why is this being done at the fb level? If we're going to use a
temporary pixmap, we should push the problem up to the DIX level where
we can actually accelerate the entire sequence of operations.

> Reverting the copying will allow out-of-bound reads by creating a
> pixman image that points outside the screen.

How does the copying version ensure that the reads will all be
in-bounds? We clearly clip to a pixmap at some point, and that code
could just as easily clip to the screen pixmap as a temporary pixmap.

Yes, we'd get pixel values outside of the window; let's fix the crash
and then argue about what the 'right' answer is.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091127/6746b3c7/attachment.pgp