djreep81 wrote:If you would suggest a long term solution, as per designing a way to merge into CEGUI allowing the scale of fonts, how would you recommend doing this at a high level? Would you still utilize freetype to raster an image of the font glyphs or something completely different? Say a different library or possibly some sort of vector approach. Glyphy is project that sends the vectors directly to the GPU. Cool idea, but only supports OpenGL ES2 renderer.
I would definitely do it similar to the way it is already done. Doing it any other way is not feasible for real-time rendering. Vector graphics rendering is not a good idea on the GPU unless you don't utilise the GPU otherwise. So for a game you would never want to do that.
Currently we render every glyph of the font separately which decreases the readability of text a lot because the letters are spaced independently of what letter they are followed by or are preceded by. If you open a book and look at the letters you will noticed that the spaces change depending on the two letters that are next to each other. For more info see this:
http://en.wikipedia.org/wiki/KerningThe correct way to solve this it to let the font library handle this. Freetype is capable of that in case there is a "kern" table, which is pretty much a deprecated table, but does not support GPos tables (
http://www.freetype.org/freetype2/docs/ ... step2.html )
There is to ways to render this. Like i said we render glyph by glyph separately. I think we can keep that up and just position the letters differently according to Kerning (correct me if i am wrong). Other than that, each chunk of text that has to be rendered per line will require a separate rectangle as geometry and will require the line to be rendered fully into a texture every time. A separate texture for each line of text would lead to a lot of different textures required to be rendered per frame. I am not sure how this would affect the performance but it would be better to use a single texture for all lines. For that some sort of alignment and fitting algorithm would be required making this so complicated it goes beyond the scope of CEGUI. I would not assume Freetype does this for us. So solution for Kerning would be either 1.) use the old way of rendering each glyph separately but position them according to Kerning or 2.) render chunks of text (each line of text) in separate textures everytime the text is changed and use a rectangle geometry for each of those lines to be rendered.
In either case, when using Kerning the "selection" size changes. We got elements like editbox which allow selecting text and the text selection will have to be adapted for that - i am not sure what changes are required though but it shouldnt be too hard to do this. The question regarding case 2.) in general is about the performance issue of redrawing the text. Usually a lot of text in applications is static. In games text might often change (counters), if this is done every frame then a texture would have to be changed every frame (or even multiple textures) and uploaded from local memory to GPU memory, which is not good at all. This would be fine only if done few times per second, but not every frame...
Another issue we have is regarding anti-aliasing. The way our Fonts are rendered doesnt use the r/g/b position of subpixels on the screen for better readability, like most operating systems and browsers do. This could be done in CEGUI but it requires a couple of changes because we apply colours to the glyphs which are just rendered black-and-white, so at severale points changes have to be made.
djreep81 wrote:1) to create large glyphs once (from the ttf), then scale down accordingly.
2) to re-render a glyph (from the ttf using freetype) each time the size (udim/area) changes.
Now to get back to your sizing issue. To ultimately solve this we would like you said require to render the glyph atlas from anew (given that we dont use the approach with one-texture-per-line and re-render-every-line-per-change) for every font size change that is required. Rendering everything in bigger sizes just once is not a good solution because the downscaling would mess up the anti-aliasing (which already isnt that great) and font readability is all about sharpness! You could try it out but I am pretty sure it would not look nice. For example render a large sized text in some font in Photoshop or Gimp or whatever, turn it from a font into a normal image/rasterize it, and then downsize it to a very small size on your screen (the smallest size that is still well readable for your eyes) with trilinear filtering (or bilinear, but not bicubic or something like that because GPUs dont have that). Create a new text in the same font but of similar font size to the one you just downsized and put it next to it. You will see the downsized one is kind of blurry on the edges and that makes it less readable, the newly created one at the target font size however should be well readable. Now, this is not the only problem. Most fonts change shape as they get bigger, for example so that they are still readable at small font sizes such as 10, 9 or 8. If you look closely you will notice that almost all good fonts do that. Some stay pixel-accurate by doing so. Now if you downsize font, you can't ever get this. 1) is therefore not an acceptable solution in my opinion. 2) Sounds better. However, if someone however has windows that change every frame and they have adaptive font sizes for the text inside them, well, then that would lead to the CPU->GPU texture upload problem i mentioned before and like you also mentioned in your post.
djreep81 wrote: Not sure how much time freetype would take to do this but i would guess very timely.
You could do a test but i am pretty sure that if you create the whole atlas of glyphs everytime this will lead to issues. An upload of the texture every frame doesn't sound like a good idea. You could try compression but that leads to other issues and is especially not a good idea with anything containing fonts.
djreep81 wrote:I would love to try to contribute to this effort. I am not very familiar with CEGUI internal code nor freetype so it would take me some time to get up to speed on everything.
We would love to see your contribution. I might have made wrong assumptions in my post so maybe you will find out something i said wouldnt work, could actually work. You would have to try it out. Additionally, i am sure that solutions for this problem can be found somehow, but it would be best to discuss them first so we are sure there are no theoretical issues, and then try it out to see there are no practical ones.
