Re: XDrawLine and optimization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Fri, 2012-03-02 at 13:03 -0900, Christopher Howard wrote:

> The code is from conky.c in conky-1.8.1. Before the loop it does one
> code:
> ----------
> XSetLineAttributes(display, window.gc, 1, LineSolid,
>     CapButt, JoinMiter);
> ----------

Non-zero-width lines are probably a bad idea.  The X spec went out of
its way to define 0-width lines as something that cheap hardware was
likely to accelerate: as long as it's translation-invariant, respects
clipping, and paints something one pixel wide, it's a legal 0-width
line.  Practically speaking drivers that accelerate this with the
hardware's line primitive end up doing GDI-like Bresenham lines, which
is what you probably wanted anyway.  I would suggest changing this to 0
first and seeing if rendering still looks acceptable; I bet it does.

XAA appears to kind of try to accelerate wide lines, in the sense that
if the driver supplies an accelerated FillSpans hook it will get used
eventually.  Naturally, from a quick scan, zero drivers implement this.

Of the three (sigh) other acceleration architectures in open drivers,
none make any effort to accelerate wide lines, and this is usually more
painful than in XAA because this occasionally triggers the migration
heuristics, which ends up pulling the whole pixmap back out of video
memory to draw a tiny little line and then putting it back up and oh
dear everything is awful.

Honestly if you're trying to do anything more complicated than 0-width
lines you probably want not to be using core X rendering anyway, and
should really look into cairo.

> And each actual line draw is preceded by a call to XSetForeground (the
> color changes in different parts of the graph).

As Peter says, this is suboptimal for remote connections since xlib
won't be able to batch successive calls.  However xlib _does_ attempt to
optimize this by checking whether you're setting the foreground color to
its current value and eliding the state change if so, so you'd win a
tiny amount if you sorted line draws by color.  Probably not something
you'd ever notice on a local display.

> ----------
> void create_gc(void)
> {
>     XGCValues values;
>     values.graphics_exposures = 0;
>     values.function = GXcopy;
>     window.gc = XCreateGC(display, window.drawable,
>             GCFunction | GCGraphicsExposures, &values);
> }

That's what I was looking for, yes.  That looks fine.  Funky values for
function (or for tile and stipple setup) can occasionally make you fall
off the accelerated paths.

- ajax

Attachment: signature.asc
Description: This is a digitally signed message part

xorg@xxxxxxxxxxx: X.Org support
Your subscription address: list-xorg@xxxxxxxxxxx

[X Forum]     [Nouveau Driver]     [Devices]     [XFree86]     [XFree86 Newbie]     [Site Home]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Video for Linux]     [Linux RAID]     [Linux Resources]

Powered by Linux