On Mon, 10 Apr 2006 11:18:46 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- 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&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
