| |||||||||||
|
| |||||||||||
X at OLSX at OLSPosted Jul 23, 2004 19:19 UTC (Fri) by oak (subscriber, #2786)In reply to: X at OLS by niallm Parent article: X at OLS
In a local case this "transfer" is function telling X server to use a
(Log in to post comments)
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..
|
|||||||||||