[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