Re: Struggling with render performance

Juliusz Chroboczek <[email protected]> writes:

> Hello,
> 
> I've started playing with a version of Ghostscript that uses Xrender
> for rendering, 

Cool sounding project.

> and I'm finding a few problems with performance.  I'm
> probably doing something wrong.
> 
> In my current setup, I'm using an 8:8:8 window and a 8:8:8:8 backing
> pixmap.  Once in a while, I blit the modified area of the pixmap onto
> the window by using XRenderComposite with PictOpSrc.
> 
> Although the pixmap and the window have the very same pixel format (up
> to the absence of alpha in the window), I'm finding the performance of
> the blit somewhat disappointing.  Am I using the wrong approach?

I think you might just be finding RENDER's performance a bit 
disappointing... Unless the combination of:

 - Your hardware 
 - Picture formats
 - Operation
 - Whether the source and dest are in video ram or not

Happens to be hardware accelerated, RENDER's performance ranges
from sort of slow to really, really slow. ("Sort of slow" is
often fast enough these days, so it hasn't been an urgent
issue.)

One possible cause of "really, really slow" is if your
destination pixmap is in video RAM and either:

 - You don't have hardware acceleration
 - Your source pixmap is in video RAM (even the drivers
   with HW accel don't accelerate this currnetly.)

A hack to force a pixmap out of video RAM that is sometimes
useful is to make it a shared memory pixmap.

> When gs's upper layers try to non-AA render something that my driver
> doesn't implement, they convert the primitive into spans and
> repeatedly invoke a method which does a XRenderFillRectangle with
> PictOpSrc; I then channel the drawing to both the pixmap and the
> window to avoid having to do a blit.  Is that okay, or do you
> recommend working with XDrawRectangle on the underlying drawables?

Long-term, they should be the same speed. I wouldn't be suprised
if XDrawRectangle is a lot faster at the moment, though.
 
> When the same thing happens with AA rendering, the method that gets
> invoked is the very same one as the one that is used when doing AA
> text; thus, I put the span into a glyphset, and do
> XRenderCompositeString8 on a one-character eight-bit-deep string with
> PictOpSrc and a 1x1 pixmap as src.  Is that okay, or should I avoid
> manipulating glyphsets when I know that the given mask won't be
> reused.

It sounds rather painful (on your end) to me as compared to simply
using XRenderComposite with an appropriate mask and the 1x1 pixmap at
the source...

[...]
 
> Finally, is it possible to add an external alpha channel to an
> existing pixmap?  I'm thinking of dynamically allocating the alpha
> channel on the first non-opaque rendering operation in cases when the
> window's pictformat has no associated pictformat with good alpha.

It should be mostly possible to emulate this by doing each 
operation twice, once on a mask, once on the main drawable and using the
'(SRC IN MASK) OP DEST' nature of RENDER. 

But I don't think this is really the right approach; I think the
right thing to do generally is to always render at 24-BPP and convert
down when rendering to the window; converting 24bpp to 16bpp when
blitting should be close to zero overhead, even if dithering.

Dithering is a little tricky:

 - You want to use different dithering algorithms for color images,
   grayscale images, and AA text.
 - But you need to dither _after_ you've finished compositing. [*]

Still, dithering as the last step is probably good enough,
especially for 24-16bpp dithering, which matters mostly for
gradients and gradient-like images.

Regards,
                                        Owen

[*] Idea I just had.... keep a separate "dither buffer", somewhat
    analogous to a z-buffer, which keeps track of the algorithm
    to use at each point.