On Wed, 6 Jun 2007 02:51:20 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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. > > jose. > > > > ------------------------------------------------------------------------- > 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. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
