>
> > Thanks for your answers, I now understand better the problem.
> > So since evas is not able to do blitting efficiently because it
> > is a too generic lib, maybe I can do it myself for special cases.
> > I actually have serious performances problems with the tree and
> > the iconbox of widgets when the viewport is big enough (lot of
> > objects to update, and a large area of the screen to redraw).
>
> really - you will use up a lot of ram for that - and likely only
> get a bit better performance. there is a combination of problems
> here.
>
> 1. moving LOTS of objects - but mostly
> 2. redrawing lots instead of blitting.
>
> 2. is the biggest problem by far.
>
> > So the only way I see to do it manually is to render the content
> > of the tree/iconbox in a buffer with the buffer engine of evas,
> > and then do my own blitting thing, and redraw things that needs
> > to be redrawn. The calculation of what will need to be blit or
> > redrawn won't be so hard because those two situations are quite
> > specific, I just have to add some restrictions, such as no
> > animated icons for the iconbox.
> > Now, before trying to do that, I'd like to have your opinion to
> > know if it will really improve the perfs: I first have to draw
> > or just blit the content of the iconbox/tree in a buffer, and
> > then display it in an image object. It adds a new rendering pass
> > so maybe it will even make the perfs worst. What do you think?
>
> doing it yourself likely won't help a lot in the end. to get to
> the "Screen" evas will STILL do a redraw of that whole region.
> you need to really be thinking of having evas detect blits. but
> thats is NOT a simple task - trust me. i have code that does it -
> in theory, but the actual rect logic needs a LOT of optimizing.
Having the "tree/iconbox" be a sub-canvas, and its view
determined by clipping the sub-canvas, could be a sound thing
to do, even if he can't do anything about the way evas gets things
to the screen :)
Actually, it would help a lot *IF* there was a flexible
enough sub-canvas notion that evas could control - eg. if it's
opaque, have the results of rendering the sub-canvas go to a
pixmap buffer, then if no sub-canvas redraws, changes in position
of the sub-canvas could be realized quickly on the top parent..
and if the clip region it occupies doesn't change, then even
better.. etc. Sound reasonable?
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
