Around 16 o'clock on Dec 29, Markus Kuhn wrote:
> I assume that is with some contemporary pixel size r. Unless you use
> some good compression technique, performance will be proportional to
> r^{-2}.
Actually, a trivial (and usable) compression scheme yields O(h) -- given
that the letterforms are fixed, run length encoding yields essentially the
same number of rectangles on a scanline, independent of the width of the
character. This is done by using PolyFillRect in place of PutImage and
works with the core protocol.
> Pixel sizes down to 0.05-0.10 mm, as we have already with laser printers,
> would certainly be desireable for e-book applications, etc.
Others have cogently argued that screen pitch will likely remain
relatively stable for some time to come -- unlike scanners and printers,
a doubling of screen pitch requires a quadrupling of critical system
resources like memory, CPU power, bandwidth and graphics coprocessor
speed. Increasing scanning and printing resolution has significantly less
impact on the system as a whole; especially as those devices often offer
scalable resolutions for performance sensitive environments.
By the time screens have doubled in resolution, I expect Render will be
relatively well established and core protocol workarounds needed only for
really old (and low resolution) hardware.
Keith Packard XFree86 Core Team Compaq Cambridge Research Lab
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
