• Show log

    Commit

  • Hash : b4cd43eb
    Author : henry
    Date : 2001-11-05T21:01:13

    Removed the stuff about restricted sets of glyphs. It happens for free now:)

  • Properties

  • Git HTTP https://git.kmx.io/kc3-lang/ftgl.git
    Git SSH git@git.kmx.io:kc3-lang/ftgl.git
    Public access ? public
    Description

    https://github.com/ulrichard/ftgl

    Users
    thodg_l kc3_lang_org thodg_w thodg_m thodg www_kmx_io
    Tags

  • README.txt

  • FTGL 1.1
    October 31 2001
    
    DESCRIPTION:
    FTGL library is a cross platform tool to allow OpenGL (www.opengl.org) to
    render characters from arbitrary fonts.
    Unlike other OpenGL font libraries FTGL uses standard font file formats
    so doesn't need a preprocessing step to convert the high quality font data
    into a lesser quality, proprietary format.
    FTGL uses the Freetype (www.freetype.org) font library to open and 'decode'
    the fonts. It then takes that output and stores it in a format most efficient
    for OpenGL rendering.
    
    Rendering modes supported are
    - Bit maps
    - Pix maps
    - Texture maps
    - Outlines
    - Polygon meshes
    
    FTGL is designed to be used in commercial quality software. It has been
    written with performance, robustness and simplicity in mind.
    
    USAGE:
    
    	FTGLPixmapFont font;
    	
    	font.Open( "Fonts:Arial");
    	font.FaceSize( 72);
    	
    	font.render( "Hello World!");
    
    This library was inspired by gltt, Copyright (C) 1998-1999 Stephane Rehel
    ( gltt.sourceforge.net)
    Bezier curve code contributed by Jed Soane.
    Demo, Linux port and gltt maintainance by Gerard Lanois
    Linux port by Matthias Kretz
    Windows port by Max Rheiner
    
    Please contact me if you have any suggestions, feature requests, or problems.
    
    Henry Maddocks
    henryj@paradise.net.nz
    http://homepages.paradise.net.nz/henryj/
    
    
    
    //========================================================================
    
    Things to think about...
    
    The whole char size thing is major headache.
    At the moment if you call font.CharSize( x) the glyph list is destroyed and
    rebuilt, which will be really, really, really inefficient if you change sizes
    often. Will the freetype cache stuff help? What about the new (FT 2.0.5)
    FTSize public api.
    
    When is the best time to construct the glyphList? After the call to Size(x)
    is the earliest but what happens if the client doesn't set the char size?
    Define a default size, check if glyphlist is valid in render function, if
    not call size with default size.
    
    Might have to move the init code out of the glyph constructors into an
    init function so that they can return errors.
    
    good site...http://cgm.cs.mcgill.ca/~luc/
    
    PROFILING
    test 1
    100,000 frames. No openGL context.
    The results of the first profile are in and as expected using freetype to
    return the char index for a glyph is costing us. A staggering 10% of the
    rendering time in fact!!! Kerning has a similar impact.
    
    test 2
    100,000 frames. No openGL context.
    Performance results for the new FTCharmap class are quite satisfying:)
    The overall render time went from 12.009 seconds down to 4.595. The
    charIndex call went from 9.066 to 1.754. My concerns about the performance
    of std::map seemed to be unfounded in this case. Kerning is still an issue
    as can be seen in the proportional difference in these figures. I don't think
    this can be resolved easily.
    
    
    Check that I do this properly..
    ============================
    
    Dave Williss a �crit :
    
    Question:
    
    If I do this...
    
        TT_New_Glyph(face, &glyph);
        for (i = 0 ; i < n ; ++i) {
            TT_Load_Glyph(instance, glyph, index[i], flags);
                ... use glyph...
        }
    
        TT_Done_Glyph(glyph)
    
    Will I be leaking memory on each call to Load Glyph or
    should I create and destroy the glyph handle for each call?
    Seems terribily inefficient but to do that, but doing it as
    above I seem to be leaking memory.
    
    
    No, this is the correct behaviour. Each call to TT_Load_Glyph
    overwrites the previous content.. and this was designed on
    purpose because the real content of a TT_Glyph object is
    _really_ complex with TrueType, and you don't want to create
    them on each glyph load..