Subject:
Re: client/server protocol speedup
From:
Morten Rolland ####@####.####
Date:
30 Mar 2000 11:37:47 -0000
Message-Id: <38E34868.9821764C@screenmedia.no>
Greg Haerr wrote:
>
> Send me a fix as soon as you feel good about it. I've made other
> changes in the pre5c I'm working on relating to bringing up
> and taking down clients, but these won't affect your shared memory
> and async patches.
Will do, but we may just disable shared memory for the time being to
be able to proceed with implementing fonts. The patch is in the
works and will probably be small, so I'll adapt it to your latest
release when I've nailed it down.
> : 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.
>
> I like the alias idea. Basically, it is a separate interpretation
> of the first parameter to GrCreateFont.
Exactly. And one that is easy to standardize and adapt.
> Keeping stuff
> as readable text is probably good, providing it doesn't start
> looking like X font descriptors.
Ugh. We don't want that, no -*-*-*-)
> BTW, future plans are to include
> inspecting the optional third parameter PMWLOGFONT that
> will completely identify a font.
In order to simplify, I have been thinking of the following:
Each font is identified by:
foundry,font-name/family-name,attributes
Foundry and attributes are optional. If you use a unique
font-name like "Times New Roman", this maps to the exepceted
font directly if no attributes are specified. If attributes
are used, they select a font within the "Times" family, as
defined by the configuration file.
I was thinking of making the attributes pure binary flags:
/*
* Attributes for the low level font rendering system.
* NOTE: This is only a proposal, as there are probably
* more that should be considered. However, it seems
* sufficient for the 35 standard PostScript fonts, and
* it is fairly compliant with the X11 font handeling
* system (It's naming convention).
*/
#define MWFATTR_ROMAN 0x00000001 /* Upright fonts */
#define MWFATTR_ITALIC 0x00000004 /* Designed slanted font */
#define MWFATTR_OBLIQUE 0x00000002 /* Generated slanted font */
#define MWFATTR_PROPORTIONAL 0x00000008 /* Variable width characters */
#define MWFATTR_MONOSPACE 0x00000010 /* Fixed width characters */
#define MWFATTR_LIGHT 0x00000020 /* Boldness */
#define MWFATTR_REGULAR 0x00000020
#define MWFATTR_MEDIUM 0x00000040
#define MWFATTR_DEMIBOLD 0x00000080
#define MWFATTR_BOLD 0x00000100
#define MWFATTR_BLACK 0x00000200
#define MWFATTR_NORMAL 0x00000400 /* Normal width characters */
#define MWFATTR_SEMICONDENSED 0x00000800 /* Semicondenced spacing/width */
#define MWFATTR_ANNOUNCE 0x20000000 /* Announce this font to applications */
#define MWFATTR_ALIAS 0x40000000 /* This is only an alias for a font */
#define MWFONT_SAME (char *)0
Various algorithms can be used to find the closest font in case
no exact attributes matched. It can be argued that boldness and
spacing should be encoded as integer fields later, so I'd say that
we state that only *one* of the width and boldness can be specified
at a time. In practical use, this should not be a problem.
The API of choice (with the current FONTID scheme) would be:
GR_FONTID font = GrCreateFont("adobe/Times",MWFATTR_BOLD|MWFATTR_ITALIC);
....
GrChangeFont(font,"Helvetica",100,MWFATTR_BOLD);
GrChangeFontSize(font,120);
GrChangeFontAttr(font,MWFATTR_ITALIC,0);
....
GrDestroyFont(font);
(The load/unload names sounds too low-level to my ears - Create/Destroy
is a more high-level description and can "allow" more flexibility in
the implementation).
> Martin has sent me an extensive patch to pre5b for freetype
> rendering. I have also made changes for freetype. I'd like to
> merge in Martin's support soon.
Do that, I'll consider the changes when making my own if they
intercept.
> When are you thinking of sending
> this work? If it's more than a week, I will probably release a
> pre5c. Most all the font changes are in the core rendering routines,
> rather than the font api itself, so it probably won't intersect much.
OK, I can't promise a date, as we have demo-time coming up, so we
may have to make do with rough edges the next week or so. Some of
the ideas I'd like feedback on as well.
> : 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)
>
> This is why I created separate PMWFONT pointers for
> each separate font instance. The time/size tradeoff is solved
> by the applications programmer by either pre-creating
> each font with attrs, or by changing the attrs on the fly.
I think giving the application programmer too much control is
not a good thing, at least if the system can not override his
choices (memory...).
> Now,
> in regards to weight/slant/width, that usually ends up calling
> the rendering library for a completely new font, vs just a size
> scaling.
Yes. Caching will hopefully make it less painless in the long
run.
> : 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?).
>
> I think this caching needs to be UNDERNEATH the GdCreateFont
> layer, so the caching would occur in the PMWFONT implementation
> for the particular renderer. (more on this below)
Yes, this is a renderer/renderer-driver issue.
> : Also, I would like to propose a change to the way fonts are
> : allocated and deallocated now: Currently, a font has to
> : be created, which results in a returned font-id. This font
> : id has to be loaded into a GC before it can be used to
> : display text. Now, the de-allocation process is somewhat
> : messy, you have to keep track of which font-ids are used
> : by which GC before deallocation can be done. GCs can have
> : invalid font handles, or a GC can be destroyed with an
> : accompanying font-handle left floating around (I have to
> : admit that I have not had time to investigate this part
> : of the source yet...)
>
> I thought through this, and don't like the idea. Fonts aren't
> the same thing as GC's and mixing them together causes
> a multitide of problems... See GsPrepareWindow for details.
I've looked into it, but the problem wasn't obvious to me,
can you explain?
Separating them may be needed on a physical level, but on the
logical level, I think they are conceptually the same thing
and should be treated as such, imho.
The fact that GdText uses a GC to decide which font to use,
while CreateFont returns something else is not good API
design in my book.
The implementation should be such that a copied GC or a GC
without a font-context (this should be possible), will not
take up unnecesary space, just like the current design.
What I don't like is thinking about how to explain this in
the documentation, and what guidelines should be given on
how to do it well.
> However, I've implemented it such that IF an application
> destroys a font, and a GC still contains it, a default font
> is used for drawing if in error. The application doesn't
> have to keep track of which GC carry which fonts.
> I think a suitable solution would
> be to add a GC flag that would state that when the GC is destroyed,
> automatically destroy the selected font also.
Pardon me for saying so, but I think this is a patch to a
problem caused by bad design, which makes the API even less
obvious and more traps open up - the question now becomes:
What if my widget destroys (a copied) GC, will a font that
I'm using elsewhere become unavailable?
By applying use-counters in the font-handle, and keeping the
fond-handle administration directly coupled to the GC, the
concept can be kept to a minimum, and this mess avoided.
> Since we still have to have font handles for the reasons
> you just gave, I don't like having GC's know about fonts
> directly.
Internally, yes we need font handles. And they need to
have multiple simultaneous users, e.g. several applications
share the same standard fonts.
> If you really have to have this, write yourself a
> GrNewGC wrapper function that creates a font and selects
> it into the GC, as well as possibly a auto-destroy wrapper
> for GrDestroyGC.
Hmm, I don't like this at all. Just so that we don't
misunderstand each other, I'll outline what I was thinking:
gc = GrNewGC();
GrSetGCBackground(gc,BACKGROUND);
GrSetGCForeground(gc,FOREGROUND);
<use the gc for drawing>
GrSetGCFont("Times",120,MWFATTR_BOLD);
GrText(w,gc, ...);
GrSetGCFontattr(MWFATTR_ITALIC,0); /* Switch to italic */
GrSetGCFontsize(100); /* 10 pixles size? */
...
GrSetGCFontattr(0,MWFATTR_BOLD); /* No more bold */
...
GrSetGCFont(MWFONT_NONE,0,0); /* Possibly release resources */
Personally I think this is very logical, and consistent with
how GCs are used today. I fail to see why fonts should not be
done through the GC, except technical issues I don't understand.
Comments?
Regards,
Morten Rolland, Screen Media
