Using XlibRectStretch for nearest-neighbor scaling (was: Re: [cairo] Cairo meeting tomorrow)

Carl Worth cworth at cworth.org
Wed Apr 4 14:21:11 PDT 2007


On Tue, 03 Apr 2007 18:53:33 -0500, Boris Zbarsky wrote:
> I know I asked this before, but the only response I really got was not exactly
> helpful.

Sorry I missed it before, (or hadn't gotten around to replying yet),
and thanks for asking again.

> Would it make sense to consider doing certain tasks (nearest-neighbor image
> scaling is the one that I was interested in) not through Render at all, if it's
> known to be possible?

Well, you've already considered it, so it definitely makes sense---(I
won't challenge the assumption that you're sensible).

And in fact, we already do this kind of thing in cairo in some
places. For example see the code in cairo-xlib-surface.c that looks
like this:

	* We can also often optimize a compositing operation by calling XCopyArea
	* for some common cases where there is no alpha compositing to be done.
	* We figure that out here as well.
	*/
	typedef enum {
	    DO_RENDER,          /* use render */
	    DO_XCOPYAREA,       /* core protocol XCopyArea optimization/fallback */
	    DO_XTILE,           /* core protocol XSetTile optimization/fallback */
	    DO_UNSUPPORTED      /* software fallback */
	} composite_operation_t;

> See https://bugzilla.mozilla.org/show_bug.cgi?id=371892 for details.  Note that
> the issue is also reproducible with FC6, so I'm not sure that the exact Render
> version involved is relevant.  The crux of the matter is that even
> nearest-neighbor scaling with Render is a lot slower than XlibRectStretch, and
> over here is even slower than client-side scaling...
>
> Basically, I don't see X server GPU acceleration of Render actually making its
> way to the install base this year, which means that while it'll be nice to have
> in the future we can't depend on it right now to resolve performance issues.
>
> Sorry to harp on this, but this is actually making my daily web browsing a
> pretty painful experience, and I'd rather not put users through it.  ;)

I don't think you're harping on anything. I don't think anybody has
ever proposed using XlibRectStretch on the cairo list before, (I don't
think I was even aware of this functions existence before now that I
recall).

Would you be interested in attempting to implement this for cairo?

-Carl

PS. One thing that should also happen is that the X server should get
fixed so that even if it doesn't have GPU-accelerated paths that it
doesn't implement things in Render even slower than existing
non-Render paths that already exist in the server. But, as you say,
you don't want to wait for new X server deployment to get the cairo
speedup you want---and we also don't need to wait for the X server to
get fixed to put the workaround into cairo.

(And for someone that does want to work on fixing these kinds of
things in the X server, cairo-xlib-surface.c should provide some
fairly reasonable documentation for the issues that we've identified.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070404/58698f87/attachment.pgp


More information about the cairo mailing list