On Wed, 19 Nov 2008 17:06:09 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
> On Wed, Nov 19, 2008 at 4:23 PM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 19, 2008 at 12:04 PM, Mikael Liljeroth > > <[EMAIL PROTECTED]> wrote: > >> Hi, I have a question regarding caching of big blocks of text. > >> The custom made evas engine that I have made for an embedded system > >> implements an eng_font_draw function that sets the context_font_ext with > >> a font_texture_draw function that renders each glyph. > >> The problem is that when there is a lot of text that changes (scrolling > >> textblocks), > >> the performance is not so good. > >> > >> When a textblock's position changes I do not want each glyph to be rendered > >> again, > >> instead I would like some kind of cache, an image buffer of the rendered > >> textblock. > >> If this is possible I could copy this image buffer to the destination with > >> only > >> one blit using a hardware accelerated blitter. > >> > >> Any ideas how this can be done? > > > > freetype and regular evas engines do that. No much way to help you without > > code. > > I think you missunderstood his request. The current engine code does > reblit all glyph when the geometry or the content of a textblock > change. We are not using any previous state information to prevent > useless and consuming redraw. > > For a faster evas_object_move of a text or textblock, we could render > the glyph to an intermediate surface and blit this surface as long as > the text and the geometry doesn't change. This would improve the move > case and the basic redraw case (when object fly over or under a > text/textblock). Not when you just modify some part of a text, nor > when you resize it without moving some part of the text. > > Currently the best place to do this would be in > evas/src/lib/canvas/evas_object_text*.c, so every engine benefit from > this. Seems to me like a huge work for not a so huge big win, but this > depend on your apps of course. as such it ends up a blit either way - 1 big blit of argb32 pixels or lots of small blits of alpha-8masks with a solid color. if you have effects (loke outline, shadow etc.) it will be slower than the argb surface "cache", if you don't it likely should be faster - though one thing that should be looked at is just all the walking code. as long as the size (width actually) remains the same for a textblock - it won't re-layout the text. it keeps a formatted list of strings and changes in format (color, style etc.) relative to the object top-left, so it just walks this list like a command queue and draws whats in the list. a cache of course means higher memory usage and now you have a tradeoff - ram for redraw. in this case i think there is a LOT of room to move in improving the redraw first. before doing a cache. cache would be much more useful elsewhere at the moment where the redraw path is always very very very fast. as such i'd advise to not use "effects" unless you really want them - they cost cycles :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
