On Wed, 11 Oct 2006 16:33:17 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > > > > Likely evas will have general obj clipping not too far away, > > > > but 'buffer evases' are also interesting and useful (hence the > > > > ecore sub-canvases). > > > > > > I think it would be indeed really useful to have such objects: > > > I may be wrong but I think this kind of objects is the way to go > > > if we want to support blitting in Evas. It should improve the > > > perfs a lot when we have to scroll large areas of screen (the > > > scrolling part would just be a subcanvas, so, in order to scroll, > > > we would just have to move this subcanvas. No need to redraw all > > > the objects of the subcanvas). We could maybe implement this in > > > the smart objects: A smart object could render (if we say so) in > > > a subcanvas, so moving the smart object won't require to redraw > > > all the sub objects. > > > > and it would increase mem usage drastically. no - there's better > > ways to do this :) > > Canvas objects in evas itself would be good to have for > various reasons - eg. simpler, more efficient implementations of > ecore sub-canvases. Could it be useful in edje...? Ummm... ??? sub-canvases definitely would be useful. they would likely not be implemented as buffers though :) > Allowing smart-objs to render to an internal evas 'buffer' > (not necessary for it to be a full sub-canvas), and having this as > a settable option, would be useful for some things that are just not > going to be possible to achieve correctly otherwise.. eg. clipping/ > coloring of complex smart objs that have members which overlap.. > same for the render-ops. Wether one would want this ability or not > is a separate matter. this would probably be the way to go - smart objects or sub-canvas objects would have an option to tell them to pre-render to a surface of their own. > However, as you mention, using sub-canvases for scrolling > very large views by moving the sub-canvas.. would be *highly* memory > intensive and thus likely not the most desirable means of doing this > (it could be used though, in some isolated cases here and there.. > depends what one might be after). yup - the solution for faster scrolling is a much more general (but much more complex) one that involves motion vectors and merging motion vector rect regions and update regions etc. to calculate what parts of a canvas have just moved (and can be blitted) and what parts need a re-render. i have prototype code i have worked on a bit to do this - but i am not happy with its performance currently so it's on the backburner. > jose. > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > 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 (東京 日本) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
