|
From: Ed R. <Ed...@tu...> - 2003-07-26 06:44:23
|
Howdy all, new programmer on the team here, and it seems my first job is to improve our font/text engine's capabilities. Without further ado, here goes. Current issues with the displaying of text: Text functions are currently scattered within the XeOpenGLRenderer and various other functions. Fonts are free-floating objects, with no current management, which is not good as they are very resource-hungry. Font/Text interaction has very limited flexability without being done by hand. Fonts have few tools to make life easier, only width/height checking. Solution: Create XeTextRenderer, make it accessable through the XeOpenGLRenderer. Encapsulate all text drawing functionality into the XeTextRenderer. Encapsulate font management into the XeTextRenderer. The XeTextRenderer will have the following capability: -Create, manage, and select fonts -Deal with rotation, vertical vs horizontal drawing. -Scale or style fonts/strings to fit inside restrictive boxes (So the text fits in the button). -Draw text on a 2d surface. -Draw text in 3d, if necessary. -Be accessible through XeOpenGLRenderer. Text drawing is extremely simple, and there should not be any problem implementing the XeTextRenderer functions anywhere, as it will be a simple call away from the renderer. The only issue will be obsoleting all the previous functions. The font memory management would probably best be done using a fairly simple font handling technique. When you want a handle to a font, you tell the TextRenderer to build it, and it will use a lazy-evaluation class (ala STL strings, one copy, many references to it) to produce the font lists. There will of course be a way to define a default text, if you just want to write something and have it be the same as "everything else". The lists are the big memory-hog anyway, so having the handles use the same lists, but different 'other variables' (everything not defined when the font is created, eg: verticality, color) should be fine. The big 'issue' is that fonts are currently used in quite a few different places in the code. I'll go ahead and keep everything backwards compatible for now, because the only place that it is heavily used is in the WinToolkit, which I hear is geared for a heavy makeover. I'll comment the functions as being obsolete in the code that are remaining for backwards compatibility. I'll go ahead and wait till tomorrow to start drawing up the .h files, to see if there are any concerns. Ed Ray -- Ed...@tu... ICQ: 2271040 |