On 5/28/07, Jason Tackaberry <[EMAIL PROTECTED]> wrote:
>
> Do you know the reason for the change to int? Was it just because none
> of the engines took advantage of it? Obviously I'd like to see
> Evas_Coord be a float. :) But perhaps the reason for the change to int
> is indicative of a deeper
On Mon, 2007-28-05 at 21:14 -0500, Nathan Ingersoll wrote:
> Evas_Coord was originally defined as a float, so you may see a few
> remnants like that. Also there was originally support for non
> one-to-one mappings of evas coordinate space to world coordinates.
Do you know the reason for the change
On 5/27/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote:
>
> I'm not sure about overhead, need to evaluate on small/embedded
> devices (I'm more than surprised by the bottlenecks I've found while
> running on omap2420/arm6/maemo).
>
> As for API, most places uses Evas_Coord, which now is typ
On 5/28/07, Jason Tackaberry <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-08-05 at 15:28 -0400, Jason Tackaberry wrote:
> >3. Lack of subpixel precision. Makes stuff like the Ken Burns Effect
> > impossible (or possible, but lame). However this is probably not
> > practical without
On Tue, 2007-08-05 at 15:28 -0400, Jason Tackaberry wrote:
>3. Lack of subpixel precision. Makes stuff like the Ken Burns Effect
> impossible (or possible, but lame). However this is probably not
> practical without a big evas rewrite.
I was thinking about this ... it sounds li
> > about that, why not doing a branch in cvs ? Branches exist for
> > that kind of stuff.
>
> a perfectly sane idea. we use branches rarely - but this is a case
> where it would be good. we should add jose to the cvs access/devs.
> jose - if you want, send me your ssh public key (id_dsa.pub in
>
On Wed, 16 May 2007 04:12:44 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
babbled:
>
> Gustavo wrote:
>
> > Great you're already doing it, at least it will serve as reference
> > if not integrated/used... is there any CVS/SVN/GIT/... we can follow
> > and do some testing?
>
> None ex
On Wed, 16 May 2007 07:53:01 +0200 (CEST) Vincent Torri <[EMAIL PROTECTED]>
babbled:
>
>
> On Tue, 15 May 2007, Gustavo Sverzut Barbieri wrote:
>
> > On 5/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> I should've added: and that involves a very large rewrite
> >> of the engin
On Tue, 15 May 2007 21:33:29 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
babbled:
>
> > > The way Carsten setup clip-object semantics in evas is
> > > that any object can clip any other, and this can be arbitrarily
> > > iterated (since a clip object can have a clip object as well).
> > > Als
On Tue, 15 May 2007 10:29:49 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
babbled:
>
> Gustavo wrote:
>
> > I want to know how difficult would be to implement support for clip
> > using gradient objects.
> > ...
> > ...
> >
> > We are willing to implement it if you give us some hints :-)
On Sat, 12 May 2007 07:16:23 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
babbled:
>
> Carsten wrote:
>
> > the advice is "i would like this and it would be good" but its not
> > trivial to do right/well and right now i really don't have the time
> > to do it - thus it's one of those backbu
On Tue, 15 May 2007, Gustavo Sverzut Barbieri wrote:
> On 5/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> I should've added: and that involves a very large rewrite
>> of the engine level internals. There is no way to avoid this -- if
>> one wants evas to be able to do much of an
Gustavo wrote:
> Great you're already doing it, at least it will serve as reference
> if not integrated/used... is there any CVS/SVN/GIT/... we can follow
> and do some testing?
None except my local copy.. and as it's partly working, partly
in the process of being worked out.. un
On 5/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I should've added: and that involves a very large rewrite
> of the engine level internals. There is no way to avoid this -- if
> one wants evas to be able to do much of anything beyond what it now
> does.
>
> It's what I've
I wrote:
> Let's take your example of an 'evas_object_transform_set'
> api function that you want.
> Ok, when you come to actually implement this, you will add
> some 'transform' to the evas object structure so that all objects
> keep the transform state. Then, when the canvas
> > The way Carsten setup clip-object semantics in evas is
> > that any object can clip any other, and this can be arbitrarily
> > iterated (since a clip object can have a clip object as well).
> > Also, an object can clip any number of objects.
>
> right now clip is all about rectangle opera
On 5/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Gustavo wrote:
>
> > I want to know how difficult would be to implement support for clip
> > using gradient objects.
> > ...
> > ...
> >
> > We are willing to implement it if you give us some hints :-)
>
> Just thought I'
Gustavo wrote:
> I want to know how difficult would be to implement support for clip
> using gradient objects.
> ...
> ...
>
> We are willing to implement it if you give us some hints :-)
Just thought I'd go back to this a bit here, and see if
I can give you an idea of what's
Gustavo wrote:
> On 5/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Carsten wrote:
> >
> > > the advice is "i would like this and it would be good" but its
> > > not trivial to do right/well and right now i really don't have
> > > the time to do it - thus it's one of those ba
On 5/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Carsten wrote:
>
> > the advice is "i would like this and it would be good" but its not
> > trivial to do right/well and right now i really don't have the time
> > to do it - thus it's one of those backburner "when i get to it"
>
Carsten wrote:
> the advice is "i would like this and it would be good" but its not
> trivial to do right/well and right now i really don't have the time
> to do it - thus it's one of those backburner "when i get to it"
> things.
Ahhh... Well, if you're going to do it.. then I'll
On Tue, 08 May 2007 15:28:16 -0400 Jason Tackaberry <[EMAIL PROTECTED]> babbled:
> On 2007-05-08 13:42, Gustavo Sverzut Barbieri wrote:
> > Motivation to do so is to have clip border as fade out instead of hard
> > "cut". We need it for our software, Canola, but talking to Freevo guys
> > show the
On Tue, 8 May 2007 14:42:37 -0300 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:
> I want to know how difficult would be to implement support for clip
> using gradient objects.
>
> Motivation to do so is to have clip border as fade out instead of hard
> "cut". We need it for our software
Jason wrote:
> 2. GL engine a second class citizen. I sometimes read on e-devel
> about how this or that isn't working properly in the GL engine.
> At some point configure was updated to no longer build it by
> default. I'm afraid one day I'll do a svn update and discove
Jason wrote:
> This is definitely a big deal for us (Freevo). We've been resorting
> to ugly hacks to get this effect in text (i.e. using Imlib2 to render
> the text to an evas image object and fiddling with the alpha channel
> after), but other hacks are increasingly impractical for use
On 2007-05-08 13:42, Gustavo Sverzut Barbieri wrote:
> Motivation to do so is to have clip border as fade out instead of hard
> "cut". We need it for our software, Canola, but talking to Freevo guys
> show the same problem.
This is definitely a big deal for us (Freevo). We've been resorting to
ug
I want to know how difficult would be to implement support for clip
using gradient objects.
Motivation to do so is to have clip border as fade out instead of hard
"cut". We need it for our software, Canola, but talking to Freevo guys
show the same problem.
I've already talked to raster about this
27 matches
Mail list logo
