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).
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?
-------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
