[PATCH 06/13] glamor: Add accelerated stipple support

[Keith Packard]

Eric Anholt <eric at anholt.net> writes:

> I'd fold set_stippled into this function, but either way is fine.

Yeah, could do, but I like the set_stippled and set_tiled functions to
take plausible arguments and have the program interface API all captured
with smaller functions.

> We should probably make sure we don't get a LARGE pixmap, right?  I
> wouldn't have thought that giant stipples were something an app would
> ever do, but your experience with java scared me.

It scarred me...

For those who weren't privy to that; the 'arduino' program, written in
java, draws all of the editor text by painting the text to images, doing
a put image and then stippling a rectangle from that. Painful and awful,
but actually common from the bad days of core X text.

Where it went pear-shaped is when it did:

        ChangeGC (gc, stipple, tile-stipple-x-origin, tile-stipple-y-origin)
        PutImage (stipple, new-text-bits)
        FillRectangle (window, gc, bounds-of-text)

Now, the X spec has always been very clear on this:

	Storing a pixmap in a gcontext might or might not result in a
	copy being made.  If the pixmap is later used as the destination
	for a graphics request, the change might or might not be
	reflected in the gcontext.

fb has always taken advantage of this by replicating power-of-two tiles
and stipples smaller than 32-bits wide to the full 32-bits available
which lets them share the same acceleration path without checking for
width at all. Before fb, mfb and cfb used to actually allocate temporary
pixmaps and rotate tiles and stipples to align with the destination.

I guess I should have anticipated that application developers would
ignore this part of the spec. In any case, instead of fighting the
applications, we'll embrace them and just have glamor track changes to
the stipple with damage, at least until glamor uses 8bpp surfaces for
bitmaps, at which point we can get rid of the temporary surface entirely.

> I'd just drop GLAMOR_CREATE_NO_LARGE into the usage flags (like we do
> for glamor_glyphs.c).  As far as I can see, that doesn't actually keep
> glamor from trying to allocate a texture that's too large, but that's
> something we can fix in glamor.c later, since it also affects glyphs.

Done.

> Other than this (and 80-column wrapping),

And, formatting fixed.

> Reviewed-by: Eric Anholt <eric at anholt.net>

Thanks!

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140507/20340636/attachment-0001.sig>