Cedric wrote:
On Fri, Jul 4, 2008 at 2:46 AM, Jose Gonzalez [EMAIL PROTECTED] wrote:
That would probably be a good way to do it. So, the vertex
coords are floats which correspond to sub-pixel precision canvas coords.
Every time one 'sets' the poly points the previous poly obj
I wrote:
Cedric wrote:
I have just one question should we expose the floating point
coordinate to the engine, or if we give it the list of points inside
the object geometry. The first solution will potentially share more
code between engine, but it could perhaps limit some
I wrote:
Carsten wrote:
On Sat, 26 Apr 2008 00:42:47 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled:
Gustavo wrote:
On Thu, Apr 24, 2008 at 3:54 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Ok, let me give you some 'criticisms' I
I wrote:
Cedric wrote:
On Fri, Jun 13, 2008 at 1:40 PM, Jose Gonzalez [EMAIL PROTECTED]
wrote:
Let's take a slightly different view on this and let's imagine
for a moment that instead of the current 'poly-point-add' api, one
had to 'set' a list of poly-points.
If one did
That would probably be a good way to do it. So, the vertex
coords are
floats which correspond to sub-pixel precision canvas coords.
Every time one 'sets' the poly points the previous poly obj
geometry
is invalidated and the new one calculated thus determining the obj's
size
Cedric wrote:
On Fri, Jun 13, 2008 at 1:40 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Let's take a slightly different view on this and let's imagine
for a moment that instead of the current 'poly-point-add' api, one
had to 'set' a list of poly-points.
If one did have
So, if anyone has any comments, suggestions, issues.. *anything* with
evas gradients -- now would be a good time to pipe in. :)
I'd _love_ using gradients, in fact I would use them much more often, _if_
not
everytime I start using them, it all feels like I'm operating a powerful
Vincent wrote:
Hey,
before putting that in bugzilla, here is what I obtain with the following
code:
[code]
o = evas_object_gradient_add (evas);
evas_object_gradient_fill_angle_set(o, 90);
evas_object_gradient_fill_spread_set(o, 1);
evas_object_gradient_fill_set(o, 0, 0,
Jorge wrote:
On Wed, Jun 25, 2008 at 2:29 AM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Gustavo wrote:
On Tue, Jun 24, 2008 at 2:40 PM, Hisham Mardam Bey
[EMAIL PROTECTED] wrote:
On Tue, Jun 24, 2008 at 12:55 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote
Michael 'Mickey' Lauer wrote:
[...]
So, if anyone has any comments, suggestions, issues.. *anything* with
evas gradients -- now would be a good time to pipe in. :)
I'd _love_ using gradients, in fact I would use them much more often, _if_
not
everytime I start using them, it
Here is a patch that add support for background preloading of a data
image. You can now, if you know what you do, ask evas to load the data
of an image in memory before it is displayed (look at the sample code
for expedite).
The code is quite simple, we have now a work queue where we
Gustavo wrote:
Here is a patch that add support for background preloading of a data
image. You can now, if you know what you do, ask evas to load the data
of an image in memory before it is displayed (look at the sample code
for expedite).
The code is quite simple, we have now a work
Gustavo wrote:
On Tue, Jun 24, 2008 at 2:40 PM, Hisham Mardam Bey
[EMAIL PROTECTED] wrote:
On Tue, Jun 24, 2008 at 12:55 PM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
On Tue, Jun 24, 2008 at 1:46 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Gustavo has
BTW, this is only tangentially related to scripting, but one thing
that's sometimes noted as an 'issue' with edje is that if one changes
the state of a part object (via evas calls), then the result isn't
updated in edje's internal description (part of the edje smart data).
you
I wrote:
BTW, this is only tangentially related to scripting, but one thing
that's sometimes noted as an 'issue' with edje is that if one changes
the state of a part object (via evas calls), then the result isn't
updated in edje's internal description (part of the edje smart data).
While I'm carrying on with this nonsense here:
Just to clarify this remark a bit.. All this really means, in this
particular case of edje, is a means by which an edje object would setup,
on each of its member parts, a function that would allow for changing
the part description
H...
Ok, let's back-up a minute here and let me ask you this: Why not
start by first having a more or less extensive set of embryo bindings
to evas objects/api?
for this to work with edje those bindings do need to be
I agree with Jose, the think we need is just the ability to add objects
from script... why instad do a simple function that create new parts? maybe
taken from another group in the same file, and then do some bindings to
basic evas functions like move, resize, etc. In this way you can create
H...
Ok, let's back-up a minute here and let me ask you this: Why not
start by first having a more or less extensive set of embryo bindings
to evas objects/api?
for this to work with edje those bindings do
this is meant to be a small sandbox to play in. generic bindings are intended
to
be powerful and generically useful- different use cases. check how bindings
are
actually done first - you have to provide all the c functions to point to (and
these in turn wrap up the actual evas/whatever
I agree with Jose, the think we need is just the ability to add objects
from script... why instad do a simple function that create new parts? maybe
taken from another group in the same file, and then do some bindings to
basic evas functions like move, resize, etc. In this way you can create
Let's take a slightly different view on this and let's imagine
for a moment that instead of the current 'poly-point-add' api, one
had to 'set' a list of poly-points.
If one did have this, it would make it much easier to deal with
the various ambiguities/inconsistencies of poly
BTW, this is only tangentially related to scripting, but one thing
that's sometimes noted as an 'issue' with edje is that if one changes
the state of a part object (via evas calls), then the result isn't
updated in edje's internal description (part of the edje smart data).
Well, one
Here's an alternative proposal with an even simpler implementation:
We take the poly points as being defined in their own coordinate system,
which happens to agree with the canvas coordinate system. Moving the
polygon will affect where the poly is rendered but not the list of poly
I wrote:
I am definitively for breaking Evas_Object Polygon API. It would be
really easier if it was more a classic Evas_Object, I really want to
have move/resize working with it. It will be easier to use and to
integrate in other application (like edje). It should help us have a
faster
Cedric wrote:
Hi,
I wanted to improve evas polygons. In the current situation, we
need to setup and destroy each polygon every time we call evas_render.
It would be nice to make it survive during two call to evas_render and
being able to modify it a little bit. Moving it around and
I wrote:
Cedric wrote:
Hi,
I wanted to improve evas polygons. In the current situation, we
need to setup and destroy each polygon every time we call evas_render.
It would be nice to make it survive during two call to evas_render and
being able to modify it a little bit. Moving
Cedric wrote:
Something's not correct with the image-size-set function,
it should be taking the externally set pixel data, and copying
it to newly created data and setting that as the image data.
Forget about the pixels-get function in that example, just
comment it out and instead
I wrote:
Cedric wrote:
I did some test around this and I think it came from the fact that
o-dirty_pixels is not set to 1 after the second call to
evas_object_image_size_set. A quick fix for your example is to call
evas_object_image_pixels_dirty_set just after
Cedric wrote:
Well, the semantics of the image-size-set function has always
been that if there is no data or file for the image, it will create
data of the requested size, and if there is data (possibly from a
file), it will create new data of the requested size and copy as much
as
Mats Ekberg wrote:
Hi Cedric and all others.
I have attached a minimal test case that shows the same behaviour as
our application code. The image size is set once, but the second time
(if there has been a rendering in between) the assertion error occurs
if the new size differs from the
Cedric wrote:
I did some test around this and I think it came from the fact that
o-dirty_pixels is not set to 1 after the second call to
evas_object_image_size_set. A quick fix for your example is to call
evas_object_image_pixels_dirty_set just after
evas_object_image_size_set. I
I wrote:
..
..
the fact that now there was basically nothing between draw calls to guard
against fp op safety - as fp ops were not being used mostly, means that it
was
much more likely u ended up with the cpu in a non emms state before doing fp
ops. even so i
Carsten wrote:
...
/* I TOLD YOU! this here STOPS the gradeint bugs. it's a missing
* emms() before doing floating point operations! the thread pipe code
* just brought it out reliably. i swear i had seen this long before i
* ever added the thread/pipe code.
*
*
Carsten wrote:
it's perfectly threadsafe. it has nothing to do with threads. it has to do
with there being no emms called before doing fp ops.
I don't think so. And emms isn't needed there without threads,
not when all funcs clean up after themselves. Disable pipes and you
Gustavo wrote:
Ok, stop you guys!
I cannot say for sure since I never played with mmx that much, but I
fear raster is right about that.
as for thread safety, registers do not need special care for threads,
no locks or other requirements, so yes, it should not have any special
care.
Gustavo wrote:
The issue isn't one of safety in the sense of circular
referencing, it's mmx/fp 'safety', ie. that we know for certain
that the execution paths aren't being interrupted in such a way
that although you think you've released mmx registers, and thus
the next guy is free
Gustavo wrote:
The issue isn't one of safety in the sense of circular
referencing, it's mmx/fp 'safety', ie. that we know for certain
that the execution paths aren't being interrupted in such a way
that although you think you've released mmx registers, and thus
the next guy is free
Carsten wrote:
On Sat, 31 May 2008 13:17:42 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled:
Gustavo wrote:
I believe it's up to OS to save/restore all the registers when you
change threads. Am I wrong?
I have no idea what happens with this, or how using multiple
...
/* I TOLD YOU! this here STOPS the gradeint bugs. it's a missing
* emms() before doing floating point operations! the thread pipe code
* just brought it out reliably. i swear i had seen this long before i
* ever added the thread/pipe code.
*
* now here is why
Diego wrote:
We decided to improve the line implementation to speed up the use of
evas-lines in python (our case). Yes, we could just use polygons, but we are
trying to reduce processor usage at this point.
Its faster to draw lines (with lines implementation) directly, specially
dealing
Anyone else looked at this? May I add the clipped smart object (no
layout stuff!) to evas? I can add some docs and even change basic
smart object to refer to this one for simple implementations.
For those who are irc challenged, maybe you could give a short
overview of what it
Gustavo wrote:
It's definitely useful to have such a ready-made simplifying
smart-class construction mechanism that could be 'overriden' - and
if you could couple that with some kind of object system for smart
data it might even be close to some aspects that the gui toolkits
already
Gustavo wrote:
Anyone else looked at this? May I add the clipped smart object (no
layout stuff!) to evas? I can add some docs and even change basic
smart object to refer to this one for simple implementations.
For those who are irc challenged, maybe you could give a short
+ * If the requested colorspace is the same as the image colorspace
+ * nothing is done and NULL is returned.
+ if (!o-cur.cspace == to_cspace) return NULL;
To cspace or not to cspace ...
-
This SF.net email is
Carsten wrote:
Yeah, and it sounds like a fine 'security minded' approach..
but in practice it's not going to make much of a difference since
edje is used along with all sorts of code that's highly insecure.
see above. it is important. it's a mistake microsoft have made all
Then one needs to extend edje/embryo scripting far more than
it's currently capable of.. and for it to be sufficiently capable
for general kinds of 'apps' it may need to have access to system
calls and other things. One'd also need to have well-known entry
points into the .edj file
Gustavo wrote:
What's the relevant notion of: self-hosting edje application?
My definition of self-hosting edje apps is an application that
doesn't need any special C code to work. See the calculator that is
referenced in the starting E-Mail from this thread.
Andreas wrote:
The calculator works nice with edje_editor, but if I open it with
edje_viewer it doesn't work. What is the preferred way to run
self-hosting edje application?
What's the relevant notion of: self-hosting edje application?
My definition of self-hosting
Andreas wrote:
The calculator works nice with edje_editor, but if I open it with
edje_viewer it doesn't work. What is the preferred way to run
self-hosting edje application?
What's the relevant notion of: self-hosting edje application?
Maybe a plain C application that does
only
Gustavo wrote:
One other aspect that needs to be addressed has to do with the
very notion Gustavo mentioned about negotiating buffer sizes that
a filter/transform might need for putting results to.. and in fact
this also covers things like calculating update rects when dealing
Gustavo wrote:
Hi guys,
As you can see from CVS log, I did some repacking of Evas_Object and
managed to save more than 80 bytes, almost 1/3 of it is gone.
While some aggressive packing went in, like layer number being a
short now, I'm a bit unsure if applying the attached patch is a
Gustavo wrote:
It was more
about having all these things (including some older stuff) that
may or may not apply to this or that obj type, no way to know,
etc. Ideally a pie in the sky kind of thing would be an evas
based on an ecore_object 'object' system (with all the ecore gui
Getting back to the evas filters/transforms stuff...
One other aspect that needs to be addressed has to do with the
very notion Gustavo mentioned about negotiating buffer sizes that
a filter/transform might need for putting results to.. and in fact
this also covers things like
Just as a change of pace from the evas filters/transforms stuff...
here's a simple ability that could be useful in evas right now.
There are many, many kinds of custom evas object types one could
define... and some of these might involve using external libs (either
in their
As we discussed at IRC, probably this policies can be handled on top
of currently existing Size_Hints and no other members should be added
to the struct.
Also agreed at IRC is that most difficult part is to get all the
requirements written, we should start with V/HBox as they're useful
and
I wrote:
There's a very simple way to have this ability in evas right,
one that requires very few internal additions and no modifications
to any of the current stuff.
That should've read ...to have this ability in evas right now,
Note that this deosn't mean that
Gustavo wrote:
One of the things I see going on with this kind of thing is
an attempt to put more and more 'widgetry/layout' kinds of needs
into evas objects in a generic way. The 'problem' with some of this
is that evas objects don't have any real notion of 'inheritance' or
I wrote:
I wish someone would point out an interesting, and/or common,
real-time gui use of something besides: one specialty filter (say a
blur or a bumpmap) followed by a geometric transform (and possibly
all clipped by a mask).
in order to do cover flow-like we
Let me give some further thoughts on your proposed api:
it should be LIKE the clipping api
filt = evas_object_filter_add();
evas_object_resize(filt, 200, 200);
evas_object_filter_effect_set(filt, EVAS_FILTER_CHILDREN_ONLY);
evas_object_filter_type_set(filt, blur/gaussian);
Gustavo wrote:
On Thu, Apr 24, 2008 at 3:54 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Ok, let me give you some 'criticisms' I have of parts of the
approaches to this filters stuff that both Carsten and Gustavo
suggested, and let me start with:
I just don't see
I wish someone would point out an interesting, and/or common,
real-time gui use of something besides: one specialty filter (say a
blur or a bumpmap) followed by a geometric transform (and possibly
all clipped by a mask).
in order to do cover flow-like we need:
1 -
Ok, let me give you some 'criticisms' I have of parts of the
approaches to this filters stuff that both Carsten and Gustavo
suggested, and let me start with:
I just don't see a realistic need for having a built-in
mechanism of arbitrary lists of arbitrary filters to be applied
to
I wrote:
This wouldn't really have any impact with the use of 'native
surfaces' - well, depends on how wide the interpretation of such.
All the engines - with the singular exeption of the gl one - use
native surfaces to do the rendering to, in one way or another.
That may
Carsten wrote:
I also know that adding any of this to evas is going to
mean a fairly large re-working of the image internals (among
other things), and that although a general 'filters' mechanism
is a very powerful thing, there are many, many aspects here
that need to be considered
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
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 -
Gustavo wrote:
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).
Gustavo wrote:
On Mon, Apr 21, 2008 at 1:04 AM, Gustavo Sverzut Barbieri
[EMAIL PROTECTED] wrote:
Jose,
I'm running out of time to reply to all of these ideas, I expect to
get back some development time after the company I started start to
calm down on the real world side (we
So, what kind of api should be provided for 'filters for evas
objects'? And how can general/loadable such filters be defined and
obtained?
Gustavo has given one possible suggestion (still needs the
issue of general/loadable ones addressed, and may want to replace
the 'set' with
PS.
Here's a distantly related issue though: One of the most common
things that people want to do with images is to rotate them (possibly
in a 3D perspective way), flip them, blur them, etc. How can one make
it easy to express such things for evas image objs (with filters) via
the
This is the kind of thing that makes 'chaining' of arbitrary
filters a problem unless very strict semantic rules are followed,
and an api used which is able to naturally represent those rules.
I'll continue this a bit later, but please do jump in
with comments or whatnot if
'Mickey' wrote:
We could put checks like this in edje_object_part_swallow. But I can't
help to
think was programmed to work this way for a reason I ignore.
All ELFs are written in this way, without error checking and reporting, i
think it's for performance reason and I like it :)
Gustavo wrote:
PS.
Some here would like to have ultimately flexible 'filters'
defined via some cpugpu supported shading language (a kind of
gfx scripting mechanism), but I seriously doubt that anyone here
is going to spend the time and effort required to design and
implement
Carsten wrote:
Anyway... Since you're still thinking about all this, and
since this has already been discussed at bossa, I'll drop the issue.
there is always room for input and discussion. until someone actually knuckles
down and starts doing this, discussion is good as it
Dariusz Knociński wrote:
Patch:
diff -u -p -r imlib2-1.4.1.000.old/src/lib/color_helpers.c
imlib2-1.4.1.000.new/src/lib/color_helpers.c
--- imlib2-1.4.1.000.old/src/lib/color_helpers.c 2007-05-21
00:58:01.0 +0200
+++ imlib2-1.4.1.000.new/src/lib/color_helpers.c 2008-04-15
Carsten wrote:
don't be too excited... it will take time to have someone to do that.
What! I thought you were working on this full-steam ahead..
Carsten said that's what you were doing! You're going to have
to speak with him about it.. slap him around a bit and throw
some
Gustavo wrote:
PS.
I'd just set a 4x4 proj transf (you can get some funky curved
stuff that way) and have utility functions for generating such in
various ways (eg. for obtaining one from four dst points, for
composing two transforms, etc.).
Ok, trying to reply to the
Gustavo wrote:
- 4x4 proj transf = good, one idea that we were considering.
That's very nice for we. :)
you mean because of me? Or because of others? At least raster, if you
ask him, he have tons of ideas on how to do things, he have considered
almost every case I
Gustavo wrote:
Filters will just be filtered by filters, so it's like
SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside
Smart Object SO1 that is filtered by F2 that is filtered by F3, O1
will get these 3 filters.
Example, F1 could be blur, while F2 be rotation and F3 be
What do you do if such a native surface is set and one asks
for the argb data? What do you do about users setting native surfaces
which don't match with the display targets somehow (differing x
resources for example).
I'd say - restrict native surface api to only have a 'get'
I wrote:
Gustavo wrote:
Filters will just be filtered by filters, so it's like
SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside
Smart Object SO1 that is filtered by F2 that is filtered by F3, O1
will get these 3 filters.
Example, F1 could be blur, while F2 be
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
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
Gustavo wrote:
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
Carsten wrote:
But what I was curious about was what exactly you had in mind
with your:
typedef struct _Evas_Native_Surface Evas_Native_Surface;
/** A generic datatype for engine specific
native surface information */
EAPI void
Thanks. :) Actually, I do have several things I was thinking
about on this, but let me just mention a kind of 'peripheral' thing
you brought up - namely, that of background loading of an image
surface.
I'm not sure I see what you mean by this - in evas. For local
files, the
Just wondering if any progress has been made on this (eg.
Gustavo, Vincent, ...?), or if anyone from the SoC is planning to
give it a try?
If not, then maybe I'll spend a bit of time to at least get the
ball rolling on this for evas.. at least get image fill-transforms
(affine ones),
Gustavo wrote:
On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez wrote:
Just wondering if any progress has been made on this (eg.
Gustavo, Vincent, ...?), or if anyone from the SoC is planning to
give it a try?
I haven't touch my development environment for a while now
Gustavo wrote:
Well, what we've discussed at BossaConference, raster, cedric and
others might complement/correct me here: add a mechanism similar to
clip as it would accumulate various filters (so rotation + shear + ...
will look fine). Make a function available for the filter to query for
Cedric wrote:
That's a pretty hefty patch. :) Do you think you could write
down some of the design/structure/etc, and what you're aiming for
here.. for the sake of posterity and mere mortals with little time
to look it all over. :)
Yes of course. So it's basically an
Cedric wrote:
Hi,
Let's really break everything ! This is the same serie of old patch
up to date that improve the cache system. It should not break
anything. The code is cleaner and should fix some bugs hard to track
in the current code base.
I want to base my work on loading image
Dariusz Knociński wrote:
Hi All,
I found bug imlib2 library (1.4.1.000) in procedure __imlib_hsv_to_rgb(...),
old alghoritm wrong
calculate internal values and produces bad result. I wrote new one and
actualy testing it. This bug
produce black bottom rect in imlib2_colorspace test
The recent discussions here about toolkit theming and such
has brought up, to me at least, the question of the future of the
etk gui-toolkit. From what I can see, there has been little or no
work done on this lib in a looong time -- it appears abandoned or
maybe just plain un-maintained
andres wrote:
Ok, my idea would be something like this. Split themes in two,
a elements.edj file and a theme_ewl.edj, theme_etk.edj, etc. file.
I think I covered all the necessary elements (I checked the test apps from
each toolkit) but feel free to extend it as you wish.
...
dan sinclair wrote:
To what end? What's the point of tying them together like this? It would
be better, in the long run, to just have a single widget library instead
of 3.
The 'one true way' of widgetry with the one true mechanism for
theming,
leading to the possibility of a
dan sinclair wrote:
The 'one true way' of widgetry with the one true mechanism for
theming,
leading to the possibility of a uniform lookfeel for 'all' apps?
Maybe. But wether 1 or 3 or 15 widget libs, it's really the
one(s) that have
apps written for them that count - and
Gustavo wrote:
On Thu, Mar 27, 2008 at 1:46 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Gustavo wrote:
On Wed, Mar 26, 2008 at 10:17 AM, Santiago Aguiar
[EMAIL PROTECTED] wrote:
I changed the patch to reflect Gustavo's comments.
I left the part table lookup to keep
Vincent wrote:
..
Then go from there and build things like an evas-3D lib if
desired.. possibly dependent on gl but able to render to any evas by
say rendering to a gl buffer and getting argb data if need be, or some
other way..
just to mention that the direct3d engine can also
Gustavo wrote:
On Wed, Mar 26, 2008 at 10:17 AM, Santiago Aguiar
[EMAIL PROTECTED] wrote:
I changed the patch to reflect Gustavo's comments.
I left the part table lookup to keep the compile time check (besides
most embryo wrapper functions do something similar). Would it be ok to
201 - 300 of 319 matches
Mail list logo
