nanogui: client/server protocol speedup
Subject:
Re: client/server protocol speedup
From:
"Greg Haerr" ####@####.####
Date:
30 Mar 2000 18:40:10 -0000
Message-Id: <00b001bf9a76$c37bc470$3017dbd0@censoft.com>
: >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 example above has a huge problem that highlights the issue with
pretending
: attributes are separate from the font name: You can't just turn of italics
(or
: bold for that matter), and expect to have a non-slanted font, unless you
: explicitly make sure that the font opened with GrCreateFont() isn't
slanted,
: and that italics is applied by software. Another reason why separating it
: doesn't really make sense.
I totally agree. It's very important that the upper level api doesn't limit
which
types of font renderers can ever be included. As Vidar points out, some
fonts
can't be italicized on the fly, they must be completed loaded from scratch.
This is primarily the reason why I designed a single GrCreateFont that
returned
a handle. Only the rotation, scaling, and attribute bits (kerning and
antialiasing)
are changable without creating another font handle. Now remember, creating
a font handle is minimal overhead with a properly written font driver. Just
because the user is requesting another handle doesn't mean any given font
must be completely reloaded.
There are other issues that aren't covered with Mortens proposal: that of
the requested character set and other potentially important font
attributes that we may want in the future. That's what the third (now
unused)
parameter PMWLOGFONT is for.
When the GC is combined with font attributes, any time another attribute for
a font is needed (say by some cooler, newer renderer), then the GC structure
has to be modified and the API extended to add that cool feature. With pure
font handles, none of this is required. Also, since Morten didn't like my
auto-destroy idea, then I suggest the original (current) design: GC
construction/
destruction never affects font handles.
I'll read thru Morten's proposal and answer some more questions shortly...
Regards,
Greg
