Keith Packard <[email protected]> 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 <[email protected]> > --- > 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 <[email protected]>
pgp5DYUMxEyFj.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
