As usual, not much time but here it goes:
On Tue, Apr 22, 2008 at 5:47 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Gustavo wrote: > > >> > Ah, I'd like to write a small prototype of this idea. It would get an > >> > ARGB buffer, get the filters as a linked list/array negotiate buffers > >> > and then process, giving the output as another ARGB buffer to check > >> > the results. Then modify this to add hardware accelerated surfaces > >> > (OpenGL). Filtes would be rotation, shear and blur since they're > >> > easier to work and can do lots of the simulation. > >> > But if someone feels in the mood to do so before, keep me informed. > >> > > >> > >> That would be a good exercise. But, don't you want to hear > >> the rest of my philosophical commentaries? :) > >> > > > > Yes I do, and actually they're very interesting at least. But I fear > > I'll not have the time to go and reply them as I'd like. > > > > Well, since you find philosophical speculations interesting, > let me throw another bit of it at you before continuing with this > filters stuff (mind you there are still a lot of things here that > I think need to be looked into). :) > > We've mentioned the semantic interpretation of these 'surface' > filters acting on an object as _functionally_ equivalent to first > rendering the object to a buffer 'surface' and having the filter > act on that surface... Ok, how about we make this former action > available thru the evas api - ie. have an api func that allows for > one to render an evas object to an evas image object, say of the form: > > void > evas_object_draw(obj, dst_im_obj, x, y, w, h); > > or something like that. > > This would be an immediate-mode call, with the semantics being > that the obj is drawn in its current state to the dst_im_obj's data > surface, ie. composite the obj with whatever the state of the dst > image surface (which can be argb data, a gl texture, an xrender pict, > etc). > > This would open up a whole new world of immediate-mode drawing > abilities to evas which haven't really been explored so far, as well > as providing a user-level buffer mechanism... It can be used in many > ways for many kinds of things... eg. it could be used in conjunction > with smart objs with render-pre/post smart-class funcs to obtain all > sorts of interesting new kinds of object types that combine elements > of both immediate-mode and retained-mode gui and design/composition > aspects. It can be used to cache the results of complex gfx constructs > (like results of filters), to create animations that involve things > like motion-blur, to .... > > And if one's clever enough, one could even find ways to add this > kind of stuff to edje. > > PS. > This is fairly easy to do right now in evas, except with the > gl engine, since one'd need to draw to gl textures and there's no > code in evas right now to do that. So, your work on the gl filters > stuff could actually be very useful for that (among other things). Yes, that's something good to have and it's basically a code refactor of the evas_render.c. As usual, I'm not sure of the impact this would cause on NATIVE surfaces and their mixing... it would be interesting to know the results of rendering with XRender to a GL surface, I wonder if it's even possible. Maybe we should have a way to say "use native" or "use software" and user would be responsible for doing that. > PPS. > You mentioned that "Filters would be rotation, shear and blur > > since they're easier to work and can do lots of the simulation." > Ummm... rotation and shear are both just specific examples of affine > transformations.. but anyway, what do you mean by 'can do lots of > the simulation'? Simulation of what? simulation of cooperative and non-cooperative filters. As you said shear and rotation could use the same affine transformation, thus being cooperative (avoiding intermediate buffer), while shear and blur wouldn't. We could do tests like: - shear + rotation; - shear + blur; - shear + blur + rotation; that's lots of simulation I'm talking... sometimes I exagerate :-) -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
