Cedric wrote:
> On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez wrote:
>
>> I wrote:
>> >> However, as I said, I have no time to work on this ATM, so if you like
>> >> to try an alternative approach, please do it. Keep it as a branch
>> >> somewhere and share your results, someone may test it and see how well
>> >> it works, maybe it would suffice and this would be integrated,
>> >> everyone is happy :-)
>> >
>> > I've already tried both approaches, and others as well. There's
>> > nothing here that's new, though there's certainly more than one way
>> > to do anything. As to some 'branch' somewhere.. maybe it's best to
>> > wait and see how your approach works out and if that would suffice,
>> > integrate it as you say.
>> > :)
>>
>> I should add that I'm in the minority here - you, vincent, and
>> raster (maybe many others) all think that the generic 'clipping' pipeline
>> is the best way to go.
>> I'd just like to see one implementation of this that works well with all
>> engines, maps naturally (in its full generality) to real-time evas obj
>> rendering, is easy for people to use, and has no
>> surprises/difficulties/semantic-issues/etc.
>>
>
> I must say that I don't really see the difference between your two
> proposal. Perhaps if you can propose the set of functions that will be
> exported by Evas to the external developper, it will be easier to
> understand and discuss.
>
>
The main difference is that of avoiding the iterative 'clipping'
mechanism as the single method for doing everything.
What you want is something like: A clips B clips C clips D clips
E clips F clips G clips H say, where H is eg. an image obj and G a
transform obj and F a rect obj and E a blur filter and D a gradient
obj and C a ..... with the result of obtaining a transformed image
which is multiplied by blurred rect which is multiplied by gradient
which is .... then composited to the dst. Also, some of these clippers
may be clipping other objs.
Very succint, very extensive... very likely to be difficult to
optimize for simple, commom-use cases, and even more likely to not
be used in this kind of arbitrary generality. Also likely to be
problematic with smart objs and difficult to use for basic things..
imagine setting a trnasform on an image obj that's already had a
rect set as a clip - one'd have to unset the rect clipper, set the
transf as the new clipper, and set the rect as the clipper of the
transform.. and that's just one example of the kinds of things that
come up with this approach.
I'm suggesting that one avoid this temptation, leave clipping
as is for now (plain rects), and instead add separate api funcs to
set a geometric trnasform, to set a mask (image or grad, no masking
a mask), and to set certain kinds of 'effects' filters (blur, bumpmap,
... possibly allow for chaining these).
If one wants more than this, then there are several ways to
obtain things - eg. introduce a 'drawing obj' type which essentially
allows for one to iterate these things by allowing one to 'add' other
objs to it (much like a group obj), including ones like it, and
extend masks to also be of this type.
Anything beyond that should probably be the domain of custom
objs that can use whatever methods/apis they have access to.. gl,
shaders. whatever.
But keep the core, built-in stuff simple, efficient, natural
and also flexible enough to obtain more complex things if desired.
-------------------------------------------------------------------------
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
