[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: Gradients for Xrender
From:       Owen Taylor <otaylor () redhat ! com>
Date:       2005-05-31 10:20:20
Message-ID: 1117534821.12508.11.camel () host-213-244 ! conf ! guadec ! org
[Download RAW message or body]


--=-CqRTi1YVUxnocAVs5wAD
Content-Type: text/plain
Content-Transfe¢Ç
.¡Ç..£Ç

Repository%ÇÔ
Entries \
ÇÄ
Entries.Log%Ç°
Entries.Backup¥Ç
.(›..¦ÇèCVS¦Ç
.¥Ç..§Ç \

Repository)ÇÔ
Entries ÇÄ
Entries.Log)Ç°
Entries.Backup©Ç
.(›..ªÇèCVSn \
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.


[prev in list] [next in list] [prev in thread] [next in thread]