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

Re: [E-devel] edje canvas objects

On Wed, 11 Oct 2006 16:33:17 GMT "jose_ogp@juno.com" <jose_ogp@juno.com>

> > > >	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)    raster@rasterman.com
Tokyo, Japan (東京 日本)