On Wed, 6 Jun 2007 02:51:20 GMT "jose_ogp@..." <jose_ogp@...> babbled:
> Gustavo wrote:
> > so, how to speed up text rendering? raster suggested me to create a
> > render cache so scaling, font and etc would be cached and maybe ...
> There are several basic ways, associated with 'caching',
> by which drawing styled text could be optimized.
> 1. At canvas level, 'draw' to engine provided "render buffers",
> and cache these on a per-obj basis as need be.
> pros. Easiest to implement.
> Would provide such buffers for other uses.
> cons. Some engine renderers, eg. gl, would need work.
> More mem use per-text-obj.
> Possible issues with some render-ops.
> A 'coarse' kind of optimization, more involved
> at the canvas level.
this also assumes the cost of rendering to the buffer then keeping it, then
rendering the pre-rendered buffer is less than doing the rendering
"brute-force". this may be the case with software - but not always the case in
all circumstances. text without any fancy style is probably by far better left
to be rendered as it is now. with a simple drop-shadow its probably best to
still do it as it is now. for other styles its better to pre-render and cache.
but this decision is probably best made by the engine. some engines - like
software-16 has specific limitations on buffers, color depth accuracy etc. and
may need to pull tricks.
> 2. Cache styled glyph 'components' as alpha (and/or color) masks.
> pros. Fastest way to draw large amounts of styled text.
> Least per-text-obj mem use.
> Can be extended to cover other text styling.
> cons. More involved implementation.
cons: doesn't work at all for styled text. you want the outline NOT overlapping
the next character to the right.
> 3. Similar to 1, but cache result of drawing, at engines level,
> to alpha (and/or color) buffers, using separate buffers for
> style 'components'.
> pros and cons. Between those of 1 and 2 above.
i lean this way myself.
> Or any combination of the above.. as desired on a per engine
> renderer basis.
> In general, 'object rendering', at the canvas level, should
> be 'atomic' -- ie. avoid drawing manipulations (that involve an obj's
> internal state) at the canvas level.
> Many extensibilty and optimization issues that evas has, stem
> from doing drawing manipulations at the canvas level.
> 1 above would bypass having to make text drawing atomic, but
> would be the easiest one to do.
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
Tokyo, Japan (東京 日本)