[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

992.0. "Should I leave the fonts loaded ?" by SMAUG::MURALI () Wed Jun 21 1989 12:54

Hello,
	Could someone tell me what's the trade of between the memory
	used up in leaving a font loaded and the performance impact
	in unloading/re-loading it. We have an application that uses
	5 fonts but only 3 are required at any time.

	Thanks in anticipation

	Murali

T.RTitleUserPersonal
Name
DateLines
992.1Request for more info on font loading/unloadingEPIK::RAMSHAWThu Feb 15 1990 17:4617
    I am also curious about the answer to the question in .0.
    
    More to the point, is there a limit on the number of fonts loaded in
    the server? I get an error when attempting to load a perfectly good
    font after I have loaded 80 others.
    
    If there is a limit:
    	Is it based on memory or number of fonts?
    	Is there a way to increase the limit?
        Is it better to 'free font' or 'unload' fonts?
    	Can I find out how memory a font uses?
    	Can I free or unload a font if text is currently being displayed
    	 using that font?
    
    Thanks for any info,
    
    	Martin Ramshaw (DECwrite developer)
992.2Depends on the version of DECwindowsSTAR::VATNEPeter Vatne, VMS DevelopmentMon Feb 19 1990 18:0332
Which O.S. are you using, and which release?  The answers are very
different depending upon the implementation and its version.

For Ultrix, I believe the amount of memory used for a loaded font
is directly proportional to the size of the font file. (I.e. a 5000
byte font file will take up approximately 5000 bytes in memory.
This ignores all the overhead data structures used to access the font
information, but I believe this is a good rule of thumb.)  There is
no limit on the number of fonts that can be loaded.  The limit
for fonts is simply the amount of virtual memory available.

For VMS, the situation is trickier.  There is a "row" cache for the
font files, so how much memory is used depends upon how much is
cached.  However, the maximum amount of memory that could be used
will be directly proportional to the size of the font files used.
The number of fonts that can be loaded is limited in VMS V5.3 to
around 80 files.  There is no documented way to raise this limit.
However, a system manager could edit SYS$MANAGER:DECW$STARTSERVER.COM
to change the file limit to a bigger number.  If you want more than
128 files, the system manager would also have to raise the SYSGEN
parameter CHANNELCNT to a bigger number as well.  I am looking into
removing the limit of 80 files for a future release of DECwindows.

From my reading of the X Window System manual, XFreeFont and XUnloadFont
are not interchangeable, therefore neither one is better than the other.
Both will free up server memory when no other resource references the font.
Also, both say that the font should not be referenced again after calling
the routine.  Of course, if you close a font, anything displayed on the
screen will still stay there.  However, the program will not be able to
refresh the display on an expose event without re-loading the font (well,
I suppose you could always save a copy of the display somewhere, but I
don't think that would be the right thing for DECwrite to do).
992.3ThanksSARAH::RAMSHAWTue Feb 20 1990 09:067
    Thanks for the info. I hit this condition on VMS 5.3 . But, of course,
    we also support Ultrix and so need to have DECwrite handle fonts on
    both platforms. Currently, we never free/unload fonts during a DECwrite
    session, obviously we have will have remedy that!
    
    Thanks,
    		Martin
992.4DECwrite release noteBBM::MJDAILEYMike Dailey; ZKO2-2/M28Wed Jul 18 1990 16:214
    DECwrite T1.1-BL3 has added a release note covering this condition and
    the workaround suggested by .2.
    
    	Mike