[I18n]Re: RENDER performance
Keith Packard wrote on 2001-12-28 19:54 UTC:
I should have monochrome text running in a week or so to give people a
chance to experiment with performance over links of various sorts. When
I've done this in other environments, I've found performance to be
acceptable down to 2B ISDN speeds; others may have different opinions.
I assume that is with some contemporary pixel size r. Unless you use
some good compression technique, performance will be proportional to
r^{-2}. With some good textual image compression systems (PNG, G4FAX,
JBIG, etc.) used on the bitmaps, performance might become proportional
to around r^{-1.3}. Pixel sizes for color CRTs have stabilized now at
around 0.22-0.25 mm, as smaller aperture masks are not feasible. But who
knows what's coming next? 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.
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: RENDER performance
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 PackardXFree86 Core TeamCompaq Cambridge Research Lab
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
[I18n]Arabic Keyboard support in xkb
Hi all, The Arabeyes Team had been working recently on adding the Arabic keyboard support to xkb nnativelyativly .. and we took some of the existing fipatchesxes ( patchs) , checked them, and we think that the changes are ready to be added to the xkb settings .. the files are in : http://www.arabeyes.org/cvsweb/projects/external/xkb/ Please tell me how can I make these changes a part of the Xfree86 xkb ? what is the needed changes ? who should I contact ? where should I go ? I really appreciate your help and support -- Yours, Isam Bayazidi Amman - Jordan = Think Linux + Think Arabic = Think www.arabeyes.org = ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
