Subject:
Re: client/server protocol speedup
From:
"Greg Haerr" ####@####.####
Date:
29 Mar 2000 20:16:54 -0000
Message-Id: <112801bf99bb$22e8f610$3017dbd0@censoft.com>
: I just came from Opera now, and there are some problems. They
: are, I think, caused by the shared memory patch, as this patch
: was against a clean 0.88pre3d IIRC without the async patch, so
: the shared memory stuff is not async clean. I'll look into
: this ASAP - as it halts opera development badly right now.
: I believe the problem only arises when using GrPrepareSelect
: and GrServiceSelect, which has only been tested in force now
: that we are adopting Opera to pre5b. Sorry about this.
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.
: 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. Keeping stuff
as readable text is probably good, providing it doesn't start
looking like X font descriptors. BTW, future plans are to include
inspecting the optional third parameter PMWLOGFONT that
will completely identify a font.
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. 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.
: 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. 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.
:
: 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)
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).
Easily solved by having the rendering implementation create a
PMWFONT but not actually calling the rendering library until
actually used to draw text... (which would finally be called
by the t1lib_gettextbits routine... which would allocate the
font)
:
: 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.
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.
:
: It would be a clean solution imho to create a font directly
: into a GC, and then leave it or change it from there.
: When the GC is destroyed, so may the particular font (unless
: others are still using it). The concept of a font handle
: will probably still be needed behind the curtain in order
: to efficiently handle multiple GCs with the same font, but
: this would be transparent to the application, and freeing
: would be limited to handeling GCs well.
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. 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.
:
Regards,
Greg
