Gradients for Xrender
Owen Taylor
otaylor at redhat.com
Tue May 31 03:20:20 PDT 2005
Content-Transfe¢Ç . ¡Ç .. £Ç
Repository %Ç ÔEntries Ç Ä Entries.Log %Ç °Entries.Backup ¥Ç . (› .. ¦Ç èCVS ¦Ç . ¥Ç .. §Ç
Repository )Ç ÔEntries Ç Ä Entries.Log )Ç °Entries.Backup ©Ç . (› .. ªÇ èCVS n NX, though we do it with some rough
edges and limitations that should be resolved in a X.org implementation.
> sense; one issue with a pure PutImage model is that MaxRequest gets in
> the way of seamless operations on large images.
Hmmm. I don't think that transferring more than 4MB in a single X request
makes sense at all, and probably even 4 MB is too much. The X client (or
Xlib, as in the current implementation) should split images in chucks in
any case, at least for performance reasons. Sending a single large request,
with a single X protocol sequence counter and without the possibility of
interleaving other requests/replies in the stream, would cause huge pro-
blems on Internet links. I'd rather like to see provision for "streaming"
large objects in multiple requests, in a way that either data is recom-
posed in the X server at the time the transferral is complete, or it is
treated as a "true" stream. This "streaming" (or "splitting" extension,
if you like) may be applied to any request, not only images, and could
be used for multimedia (for example audio), or to better implement a X
layer granting access to client devices (disks, USB ports, printers).
/Gian Filippo.
More information about the xorg
mailing list