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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com