nanogui: client/server protocol speedup


Previous by date: 29 Mar 2000 20:17:35 -0000 Re: client/server protocol speedup, Greg Haerr
Next by date: 29 Mar 2000 20:17:35 -0000 Re: Unicode, Morten Rolland
Previous in thread: 29 Mar 2000 20:17:35 -0000 Re: client/server protocol speedup, Greg Haerr
Next in thread: 29 Mar 2000 20:17:35 -0000 Re: client/server protocol speedup, Greg Haerr

Subject: Re: client/server protocol speedup
From: Martin Jolicoeur ####@####.####
Date: 29 Mar 2000 20:17:35 -0000
Message-Id: <38E262B4.E6B2B34@visuaide.com>

>
> On fonts;
>
> I have a patch on the drawing board that will result in a
> more configurable Microwindows, and esp. nano-X WRT font
> support.  The model is a more abstract font handeling system
> where fonts and aliases can be registered, including font
> attributes (from a config file f.x.).  With the new system, you
> can request a font named "Times New Roman", which can be an alias
> for a font in the "Times" family with certain attributes, that
> points to a freely available font with a different name.
> Since the font system knows the font family name of the selected
> font, you can later request "Italic" or "Bold", and you will
> get these versions of the "Times New Roman" font in the
> "Times" family.
>

This kind of mechanism works well with western languages like english,
french, spanish ... But when it comes to CJK languages you may come to
find that font names and families are not so standard. "Times", "Arial"
and such are copyrighted names owned by foundries ... my 0.02$

>
> There are some implications here; The font system will have
> to be able to automatically reload other fonts when changing
> font attributes (weight, slant, width) - but this is needed
> in one form or another anyway, as Opera requests fonts on a
> frentic basis when rendering a page (think of loading two
> frames simultaneously, each with a different font, or just
> generally formatting an ugly page with all sorts of fonts..).
>
> Loading and keeping all the fonts needed would result in
> unpredictable memory usage, which must be prevented on small
> devices, so a true LRU cache should be implemented at the
> rendered glyph level (in the rendering libs?).  By loosening
> on the semantics of the Create/Unload (which should
> really be Create/Destroy, or Load/Unload?), this can be
> achieved in the nano-X server transparently (e.g. not
> neccesarily unload a font immediately when an application
> requests this - it may change its mind and resume the font
> soon).
>
>

All this automatic font loading/unloading and cache stuff should really
be at the nano-X level, IMHO. But since I think this will be overkill
for what we need here, would it be possible to keep a simple manual
load/unload mechanism like it is right now too ? (both mechanisms are
not mutually exclusive)

(Maybe load/unload would be better than create/unload, though :-))

Regards,

Martin Jolicoeur
GVT Project
####@####.####


Previous by date: 29 Mar 2000 20:17:35 -0000 Re: client/server protocol speedup, Greg Haerr
Next by date: 29 Mar 2000 20:17:35 -0000 Re: Unicode, Morten Rolland
Previous in thread: 29 Mar 2000 20:17:35 -0000 Re: client/server protocol speedup, Greg Haerr
Next in thread: 29 Mar 2000 20:17:35 -0000 Re: client/server protocol speedup, Greg Haerr


Powered by ezmlm-browse 0.20.