On Wed, Nov 19, 2008 at 2:06 PM, Cedric BAIL <[EMAIL PROTECTED]> wrote: > 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.
well, freetype caches glyphs as images, so it's basically a copy, ok we use it as an alpha for color (if grayscale), but should be almost the same speed. what it does not is to cache effects. because engines know nothing about effects. I discussed this with raster, opengl, for example, could easily apply blur to get soft-shadow, but then this would make each engine more complex... as you said, it's not a big win, so it's postponed. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------- 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
