On 12 October 2012 15:28, Henrik Sperre Johansen <[email protected]> wrote: > On 12.10.2012 14:42, Igor Stasenko wrote: >> >> On 12 October 2012 13:41, Tudor Girba <[email protected]> wrote: >>> >>> Hi, >>> >>> Athens would indeed be great. And I am happy that this investment has >>> high >>> priority in the team. But, I think for the usages that I see, we would >>> need >>> font support. Is there any progress on this front? >>> >> Font support is there. I currently working on Morphic rendering (see >> screenshot) and getting VMs for all 3 platforms Athens-ready. >> >> As i said previously, don't expect Athens to support raster fonts. It >> doesn't makes any sense. >> With athens, you can always render number of glyphs into bitmaps and >> draw them as bitmaps later, if you want it, >> but i wouldn't call it 'font support', it is bitmap support. :) >> >> For Cairo backend i did integration with freetype (which already in >> pharo as you know), which means that you can >> render any scalable fonts. >> >> And if you may know, freetype package supports embedded fonts (i.e. >> font data loaded from memory), >> which means you don't even need to have a separate font file along the >> image, you can keep font in image itself. >> As for amount of memory, needed to hold truetype font in image: >> we did a small experiment with Camillo few days ago , we took single >> font (Deja Vu sans mono), >> and edited it to have only ascii character set (0..127). The resulting >> font file size is just 30Kb! >> >> Now compare it with following: >> >> (StrikeFont allInstances collect: [:each | each glyphs bits sizeInMemory >> ]) sum >> 1504444 >> >> 1.5 Mb of bitmap data for only single raster font with couple fixed sizes. >> >> For same size, you could have 1500/30 = 50 various vector fonts (if >> only ascii character range of course). > > 25 then, StrikeFonts cover all of latin1 range :) > How is the rendering performance compared to Bitmap and FT fonts done > without athens/cairo? > Bitmapped FT fonts were somewhat of a hog both memory and performance-wise > iirc, due to the combination of sub-pixel accurate glyph bitmap cache and > glyph-by-glyph rendering... > According to my measurement, which i did a while ago, a freetype glyph rendering roughly takes 1/3 of total time for delivering glyph to the screen. Which means a worst slowdown if you do it without any caching is +1/3 total rendering time for text. This actually shows that rendering is memory bound. Freetype producing grayscale glyphs 8 bit per pixel, and blitting it on screen uses 32 bit bitmap . That's the only one reasonable explanation to my observations i found.
> Impressive progress! > > Cheers, > Henry > -- Best regards, Igor Stasenko.
