On Sat, 17 Dec 2005 18:40:50 +0900 Carsten writes:
> On Wed, 14 Dec 2005 02:19:56 -0500 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> >
> >
> > On Wed, 14 Dec 2005 14:43:50 +0900 Carsten writes:
> > > On Tue, 13 Dec 2005 23:38:43 -0500 Jason Tackaberry
> <[EMAIL PROTECTED]>
> > > babbled:
> > >
> > > > On Tue, 2005-12-06 at 15:32 +0900, Carsten Haitzler wrote:
> > > > > yeah - we ALSO need arbitratry clipping to any object, with
> an
> > > added option
> > > > > of pre-rendering all objects to be clipped by a clipper to a
> tmp
> > > buffer,
> > > > > unlike
> > > >
> > > > I'd settle for extending the current approach to support
> gradient
> > > > objects as well, so that we can have a text fadeout effect.
> > > >
> > > > Currently I'm using this enormously brutal hack where I use
> Imlib2
> > > to
> > > > render the text, modify the pixels directly, then use
> > > > evas_object_image_data_set on an Evas image. Ugly. :)
> > >
> > > very ugly. the idea is that u could clip USING a gradient object
>
> > > thus get what
> > > u want. but for that we need pixel mask multiplication (render
> clip
> > > mask,
> > > render all objects to be clipped by it to a tmp buf, now
> composite
> > > tmp buf to
> > > destination, free tmp mask). when rendering the mask we can make
> a
> > > few
> > > shortcuts like cutr it up into only sub-object intersection
> regiosn
> > > so we onyl
> > > render/calculate the regions of the mask we will be needing for
> > > multiplied dest
> > > composite :)
> > >
> > Yeah, but you know the real difficulty here isn't the gfx
> > aspects, at least not with the software based engines -- it's with
> > the canvas level clipping semantics...
>
> well at the evas api level its expandable and ok. at the engine api
> level its
> bad atm.
>
The general clipping notion will *only* work coherently if an
object may clip at most one other object. To 'clip' several objects
one'd need to make them 'members' of some 'container' object (a smart
obj, or a sub-canvas, or whatnot).
But the canvas semantics *must* respect the single-clippee
constraint.
At the api level this requires no changes, and for the canvas
internals it is actually a simplification (also need to remove the
smartobj clip_object_set and color_set functs).
The problem is (from what little I've looked at of edje),
that going thru with this seems like it would break edje as it is.
You'd need to make sure, when the format specifies multiple
objects being 'clipped' by some object, that you collect these
into a separate smart obj that will be the actual clipped obj.
If you can do this.. then the evas changes are not difficult
(at least not for the software based engines).
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
