| |||||||||||
X at OLSX at OLSPosted Jul 23, 2004 11:46 UTC (Fri) by corbet (editor, #1)In reply to: X at OLS by niallm Parent article: X at OLS Sorry, I was in a hurry. "Anymore" because things have really changed; back when X11 was first designed and implemented, there was nowhere near as much image data in the stream. As far as compression: one does not communicate images to the server in a format like JPEG; at that level in the protocol, you're dealing with basic raster line data. More to the point, though: much of this image data is created by the client; glyphs and such. Jim said you can get up to 1:300 compression on some of that stuff.
(Log in to post comments)
X at OLS Posted Jul 23, 2004 12:49 UTC (Fri) by niallm (subscriber, #3923) [Link] Thanks Jon.It occurs to me that there's something just a little bit suboptimal in the scenario where a JPEG is retrieved by a web browser from a remote site, which is then rasterised and transferred to an X server at a couple of hundred times the bandwidth and CPU usage! Hopefully Jim will be able to apply some clever ideas to this.
X at OLS Posted Jul 23, 2004 19:19 UTC (Fri) by oak (subscriber, #2786) [Link] In a local case this "transfer" is function telling X server to use acertain shared memory segment. I don't think it makes sense to compress shared memory for the sake making it smaller, on blitting it needs to be uncompressed anyway. :-)
X at OLS Posted Jul 29, 2004 7:02 UTC (Thu) by chepelov (guest, #23542) [Link] unless your client (browser) is living on a different machine from the server (X).In that case, you have to get the (http)client (the browser, again) to download the JPEG, decompress it into the client machine's memory, just to send it back to the X server over the network. This is what the parent is complaining about. IIRC, there's a JPEG extension around (I think I saw that close to freedesktop.org). The idea being that the browser would use the extension to keep the image compressed all the way to the X server. If the server and client live on the same machine, the same CPU will decompress it anyway, so there should be no penalty. If server != client, then you win. Really, using Mozilla over a 10Mbit/s LAN is no fun nowadays...
X at OLS Posted Aug 3, 2004 14:12 UTC (Tue) by kzin (guest, #841) [Link] The browser would have to open and read the JPEG file anyway before sending it to the X server, for a variety of reasons, not the least of which being security.
X at OLS Posted Aug 5, 2004 9:07 UTC (Thu) by renox (guest, #23785) [Link] Can you elaborate?I'm not sure how decompressing a JPEG file may be a security problem, either it decompress correctly or it doesn't and the X Server should return an error to the browser, but how is this a security problem?
Of course in case of decompression error, there is a loss of performance due to the unneeded transfer of the JPEG, but errors should be very rare..
|
|||||||||||