[PATCH 06/13] glamor: Add accelerated stipple support
Eric Anholt
eric at anholt.net
Tue May 6 12:21:01 PDT 2014
Keith Packard <keithp at keithp.com> writes:
> This copies the stipple to a 8bpp pixmap and uses that to paint the
> texture from.
>
> v2: Create deep stipple pixmap without GLAMOR_CREATE_FBO_NO_FBO
>
> v3: Fix stipple origin sign (matches tiles now). Track changes
> to original stipple with damage. This isn't required by the
> X spec, but java appears to depend on it, so we'll just do it.
> When Glamor switches to 8bpp bitmaps, we'll be able to render
> directly from them and not need this anymore.
>
> Signed-off-by: Keith Packard <keithp at keithp.com>
> ---
> glamor/glamor_core.c | 58 ++++++++++++++++++++++++++++++++++++++++
> glamor/glamor_priv.h | 5 ++++
> glamor/glamor_program.c | 35 ++++++++++++++----------
> glamor/glamor_transform.c | 68 ++++++++++++++++++++++++++++++++++++++++++++---
> 4 files changed, 149 insertions(+), 17 deletions(-)
>
> diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
> index 9d941d7..26eb867 100644
> --- a/glamor/glamor_core.c
> +++ b/glamor/glamor_core.c
> @@ -396,7 +446,11 @@ glamor_validate_gc(GCPtr gc, unsigned long changes, DrawablePtr drawable)
> changes &= ~GCTile;
> }
>
> + if (changes & GCStipple)
> + glamor_invalidate_stipple(gc);
> +
> if (changes & GCStipple && gc->stipple) {
> +
> /* We can't inline stipple handling like we do for GCTile because
> * it sets fbgc privates.
> */
stray whitespace change.
> diff --git a/glamor/glamor_program.c b/glamor/glamor_program.c
> index 0e3e94d..ba9333e 100644
> --- a/glamor/glamor_program.c
> +++ b/glamor/glamor_program.c
> @@ -51,42 +51,49 @@ static const glamor_facet glamor_fill_tile = {
> .use = use_tile,
> };
>
> -#if 0
> static Bool
> -use_stipple(PixmapPtr pixmap, GCPtr gc, glamor_program *prog)
> +use_stipple(PixmapPtr pixmap, GCPtr gc, glamor_program *prog, void *arg)
> {
> return glamor_set_stippled(pixmap, gc, prog->fg_uniform, prog->fill_offset_uniform, prog->fill_size_uniform);
> }
I'd fold set_stippled into this function, but either way is fine.
> diff --git a/glamor/glamor_transform.c b/glamor/glamor_transform.c
> index d6ba564..87f8dda 100644
> --- a/glamor/glamor_transform.c
> +++ b/glamor/glamor_transform.c
> @@ -198,6 +198,60 @@ glamor_set_tiled(PixmapPtr pixmap,
> size_uniform);
> }
>
> +static PixmapPtr
> +glamor_get_stipple_pixmap(GCPtr gc)
> +{
> + glamor_gc_private *gc_priv = glamor_get_gc_private(gc);
> + ScreenPtr screen = gc->pScreen;
> + PixmapPtr bitmap;
> + PixmapPtr pixmap;
> + GCPtr scratch_gc;
> + ChangeGCVal changes[2];
> +
> + if (gc_priv->stipple)
> + return gc_priv->stipple;
> +
> + bitmap = gc->stipple;
> + if (!bitmap)
> + goto bail;
> +
> + pixmap = glamor_create_pixmap(screen, bitmap->drawable.width, bitmap->drawable.height, 8, 0);
> + if (!pixmap)
> + goto bail;
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.
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.
Other than this (and 80-column wrapping),
Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140506/dedbaa82/attachment.sig>
More information about the xorg-devel
mailing list