This bandwidth issue will be with us forever. How about adding a short section of "Advice to implementors and users" to the render protocol description. Or it could be a separate paper with a reference in the protocol. But something so that a common initial understanding can be built up.
There are two related performance issues: 1) bits transmitted - it is useful to minimize these, 2) synchronous round trips - these are orders of magnitude more costly than bits transmitted. It is worth sending 10-100x more bits if there is a corresponding reduction of round trips. An explanation of how to send glyphsets efficiently, reference them efficiently, and indicative numbers on how display of a page of text translates into bits and round trips would then orient people. It would also help eliminate poor implementations by new implementators and applications. I think that including realistic numbers would help a lot. As for networks, there is a real need to keep X usable over network links. I personally find something like 90% on machine / 9% over LAN / 1% over WAN. I would hate to lose that 9% or 1% because even though they are a small part of my usage, they are an important part of my job. WAN link speeds are not going to improve dramatically over the next decade or two. The speed of light problems are intractable, and the installed infrastructure changes slowly. True, I can upgrade a clean fiber to 140Tb/sec. But the real problem is how fast can I transmit from office A at site A to office B at site B, for thousands of sites. That speed limit changes slowly. It may even decrease on average with people exploiting wireless and cable technologies that trade bandwidth for flexibility, cost, and distance. Nothing will change the 10-20ms minimum for a round trip. That is a speed of light limit, and with most routing paths you are hard pressed to even get close to that limit. Typical LAN speeds will probably deteriorate. Again, this is an infrastructure issue. With an expensive infrastructure I can put in 1 Gb/s LAN. For real cheap I can use wireless, phone cable, or 100 Mb/s. Those other technologies are mostly down in the 1-10 Mb/s range. Cost and flexibility will drive increased use of the slower technologies. I think that we should target: - usable, fast text using non-AA fonts over 50/25 kbps with o(10)ms round trip. (I'm using client/server transmit speed notation. 50/25 could be a 56K modem or a low power wireless data.) - borderline, sluggish text using AA fonts over 50/25. - usable, fast text using AA fonts over 768/128 (e.g. DSL, cable, wireless) - immediate text, OK graphics and images over 10,000/10,000 - immediate text, fast graphics and images over 100,000/100,000. >From what I've seen the current X and Render do meet these goals with at least some applications. So I think that my request is much more one of explaining what has already been accomplished and then avoiding new problems as it evolves. R Horn _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
