[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas vs Gtk/Gdk: why the difference of perfs is so impor tant?

> > 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?