On Tue, 5 Jun 2007 01:00:37 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> As you might know I'm working to get Evas running as fast as possible > due our desire to use it in embedded systems, to name Nokia N800 and > OpenMoko. > > One of the drawbacks are how fonts are drawn, specially with styles > and not cached at all, so every time you move a text around, you go in > a long call tree that bails down to: > > src/lib/engines/common/evas_font_draw.c: evas_common_font_draw() > > this function, while huge and kind of messy (splitting it into > multiple "static inline" with specific purposes would help), is not > slow... at least I couldn't spot anything obvious by quick read (no > profile or test so far). > > 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 reused well this was more for text styles. you really are not going to improve on basic text drawing (simple text with a color). it's the outlines, soft drop shadows etc. etc. that really eat up resources. > in a later point (moving text would have the same cost as moving > semi-transparent images)... extending it further we could have images > pre-colorized or already multiplied by alpha. colorizing does cost, but not as much as styles. and remember the price you pay is in extra memory usage. if you have lots of memory to kill - fine, but it is not always a good idea to expand into pre-rendered caches for everything. you need to think about how expensive the operation really is. the cost of rendering to a buffer first, then copying/blending to screen does exist - and you don't want to add it everywhere unless it will really get you a speedup worth the price you pay in ram. > Of course this makes sense and would help a lot, except things > that changes a lot (you'd never use the cache in these situations)... > so we'd need a way to avoid caches for these things. I will leave this > problem out for now. or require a higher entry point into the cache - not just a "first time its used", but put in a cache node the first time a certain input is used (string + colors, styles etc. or images + colors/transforms) and once used ENOUGH its put into cache. (cache node is filled). > What I want your feedback is: > - ideas to improve font drawing alone? (evas_font_draw.c) i am not really sure you can do a lot. the biggest costs we pay are generation of a hash per character, a hash table lookup, and function calls per char. actually calling a fn is a fair bit of overhead when you are doing it at this level. > - where to do cache? (and why) > 1) evas_common_font_draw() > 2) software_generic/eng_font_draw() > 3) canvas/evas_object_text_render() > 4) canvas/evas_render evas_render_updates_internal() and other > callers of obj->render() i am thinking that the cache is best done in the engine. this means 2. the gl engine has no need to cache - it can manage it via brute force. caching will be more expensive due to other costs with gl (eg power of 2 textures, or lack of render-to-texture extensions etc.). also once you run out of video ram in gl - your performance will drop so far that you may as well just software render. we want to avoid using memory if we dont need it (for textures). for software - the generic software engine can handle it. xrender will need to re-implement that, but its way of caching will be different with pixmaps etc. > my understanding so far is that 4 provides "cache everything" without > much duplication, but it will be hard (or impossible) to cover every > object right, in other words, it would not be as extensible as > desired. > So my next option would be inside object's render implementation > (evas_object_text_render()), just change destination surface to be a > object-owned buffer and then use memcpy() or other blit function from not all engines can provide buffers you can render to like that :( if you do it at the engine level, we need to put the concept of styles INTO the engine. this is ok - it's a good idea. this also means the engine CAN share cached buffes/images/pixmaps per string that shares the same properties (same font, size, colors and styles as well as same string content). > this buffer to real output buffer. This would need per-object > implementation, but that gives us extensibility... actually few > objects need cache, text and non-accelerated scaled images come to > mind. At this point we have enough information to check for cache > validity and we can also trap setters and getter to invalidate cache > as soon as possible... maybe even add specific functions to > enable-disable cache (evas_object_text_cache_set(o, 1)). > > I plan to start profiling and work on possible improvements to > evas_font_draw.c on Thursday, then next week to this cache idea, so > comments before this date are really appreciated. :-) imho - i think the best way is 1. move font style rendering into the engine. that means later it can do "soft" drop shadows via real gaussian blur etc. etc. or whatever mechanims the engine can manage 2. it can cache things using engine-level primitives. 3. the more you abstract to an engine, the more it can optimize (but at the same time the less the canvas can do all in 1 place for everyone). > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Jabber: [EMAIL PROTECTED] > MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > > ------------------------------------------------------------------------- > 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
