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



On Mon, 10 Apr 2006 11:18:46 GMT "jose_ogp@juno.com" <jose_ogp@juno.com>
babbled:

> > 
> > > 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 :)

could - but likely not. a canvas brings in a fair bit of overhead, and a
sub-canvas will then be stuck to always software rendering too... :) as it
currently stands.

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

possibly - but pushing poo uphill. you could do this with smart objects too -
if i got around to making child object positions parent-relative. a sub-canvas
is nothing more than a different kind of smart object (that comes with its own
buffer). i still think the way to go eventually is detect blits. as i said - i
have code that can do this... in theory. it needs work though.

> 
> 
> 
> 
> -------------------------------------------------------
> 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_______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)