On Thu, Jun 19, 2008 at 1:09 AM, Enlightenment CVS
[EMAIL PROTECTED] wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/lib/canvas
Modified Files:
evas_object_main.c
Log Message:
bad *alloc! bad sizeof usage.
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
Thank you all for fixing it :)
Now Edjy can work on everyones systems! Yay! :)
Toma
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
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.
*
*
On Sat, May 31, 2008 at 4:28 AM, Jose Gonzalez [EMAIL PROTECTED] wrote:
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
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.
On Sat, May 31, 2008 at 1:05 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
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
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
On Sat, May 31, 2008 at 2:19 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
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
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 cpu
cores affects that.
that
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
On Sat, 31 May 2008 01:41:53 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled:
...
/* 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
+ * 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
On Tue, 13 Nov 2007 12:15:39 +1100,
Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote :
On Wed, 10 Oct 2007 18:23:56 +0200 Christian Hunke
[EMAIL PROTECTED] babbled:
Its only the out-commenting of the constants in evas_object_main.c.
When you just undo this it already works:
: Re: [E-devel] E CVS: libs/evas raster
Hi,
This patch somehow broke ETK. I just reverted it and it works fine. To
test just run etk_test and select the tree test, then try to scroll
the list using the scrollbar button. Nothing happens. I don't have
time to work on it right now
Nachricht-
Von: Andre Magalhaes [EMAIL PROTECTED]
Gesendet: 06.10.07 02:49:58
An: enlightenment-devel@lists.sourceforge.net
CC: [EMAIL PROTECTED]
Betreff: Re: [E-devel] E CVS: libs/evas raster
Hi,
This patch somehow broke ETK. I just reverted it and it works fine. To
test just run
On 10/5/07, Enlightenment CVS [EMAIL PROTECTED] wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/modules/engines/software_sdl
Modified Files:
evas_engine.c
Log Message:
cedric's sdl patch.
Ops! You
On Fri, 5 Oct 2007 11:14:45 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
On 10/5/07, Enlightenment CVS [EMAIL PROTECTED] wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/modules/engines/software_sdl
Hi,
This patch somehow broke ETK. I just reverted it and it works fine. To
test just run etk_test and select the tree test, then try to scroll
the list using the scrollbar button. Nothing happens. I don't have
time to work on it right now, but if somebody can take a look at it,
it would be great.
On Sat, 4 Aug 2007, Enlightenment CVS wrote:
- evas_common_image_free(im);
+ evas_common_image_delete(im);
dc-render_op = op;
dc-clip.use = cuse;
if (!gr-tex) return;
===
RCS file:
On Sat, 21 Jul 2007 00:32:27 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
On 7/21/07, Enlightenment CVS [EMAIL PROTECTED] wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/lib/canvas
Modified Files:
On 7/21/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
On Sat, 21 Jul 2007 00:32:27 -0300 Gustavo Sverzut Barbieri
still about minor optimizations, do you think it worth to remove
and ; since they're always present?
which ones?
from escape_strings:
lt;\0\x3c\0 - lt\0\x3c\0
On Sat, 21 Jul 2007 03:54:18 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
aaah. the standard escape delimiters - i guess it makes sense to remove them. i
can't think of needing to have a different escape handler at the moment.
On 7/21/07, The Rasterman Carsten Haitzler [EMAIL
On 7/21/07, Enlightenment CVS [EMAIL PROTECTED] wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/lib/canvas
Modified Files:
evas_object_textblock.c
Log Message:
no need for extra nul byte check - while
On Tue, 10 Jul 2007 00:54:04 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
On 7/9/07, Enlightenment CVS [EMAIL PROTECTED] wrote:
+ * EVAS_COLORSPACE_RGB565_A5P:
+ *
+ * In the process of being implemented in 1 engine only. This may change.
+ *
+ * This is a pointer to image
On 7/9/07, Enlightenment CVS [EMAIL PROTECTED] wrote:
+ * EVAS_COLORSPACE_RGB565_A5P:
+ *
+ * In the process of being implemented in 1 engine only. This may change.
+ *
+ * This is a pointer to image data for 16-bit half-word pixel data in 16bpp
+ * RGB 565 format (5 bits red, 6 bits green,
On Sunday, 03 June 2007, at 02:18:02 (-0300),
Gustavo Sverzut Barbieri wrote:
(i cannot fix gmail to detect .diff as text)
Try using the correct extension of .patch instead. :-)
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED]
n + 1, Inc.,
On 6/3/07, Michael Jennings [EMAIL PROTECTED] wrote:
On Sunday, 03 June 2007, at 02:18:02 (-0300),
Gustavo Sverzut Barbieri wrote:
(i cannot fix gmail to detect .diff as text)
Try using the correct extension of .patch instead. :-)
.patch or .diff are detected as octet-stream by most
On Sunday, 03 June 2007, at 14:48:15 (-0300),
Gustavo Sverzut Barbieri wrote:
.patch or .diff are detected as octet-stream by most browsers
(firefox) and gmail, so I need to send then as .txt to get accepted
Unfortunately, octet-stream isn't really a MIME type, it's a
fallback that could be
On 6/3/07, Michael Jennings [EMAIL PROTECTED] wrote:
On Sunday, 03 June 2007, at 14:48:15 (-0300),
Gustavo Sverzut Barbieri wrote:
.patch or .diff are detected as octet-stream by most browsers
(firefox) and gmail, so I need to send then as .txt to get accepted
Unfortunately, octet-stream
Attached is my improved version of evas_tiler del_redraw(), also minor
improvements for add_motion_vector (is it used at all?).
I've also added an extra merge step before get_render_rects(), since
del can leave some room for merging.
--
Gustavo Sverzut Barbieri
On Sat, 2 Jun 2007 17:04:34 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
attached... nada! :(
Attached is my improved version of evas_tiler del_redraw(), also minor
improvements for add_motion_vector (is it used at all?).
I've also added an extra merge step before
On 6/2/07, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
On Sat, 2 Jun 2007 17:04:34 -0300 Gustavo Sverzut Barbieri
[EMAIL PROTECTED] babbled:
attached... nada! :(
ok, again and with you in the list, so if list blocks you still get it.
we should really fix this list to accept more
On 4/30/07, Vincent Torri [EMAIL PROTECTED] wrote:
It seems that a lot of eng_* functions do not test 'data'. Should we add
that test in these functions too ?
probably not since you won't get that far.
I could trigger that situation when doing evas_free() on a just
created evas_new() without
It seems that a lot of eng_* functions do not test 'data'. Should we add
that test in these functions too ?
Vincent
On Mon, 30 Apr 2007, Enlightenment CVS wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir :
On Tue, 6 Mar 2007 00:40:44 -0500 Michael Jennings [EMAIL PROTECTED] babbled:
On Tuesday, 06 March 2007, at 05:06:04 (+),
[EMAIL PROTECTED] wrote:
Well, that's probably too drastic. It's still really an
optionally compiled, loadable module, and raster's last mods seem
to have
Why not just file a bug?
http://bugzilla.gnome.org/browse.cgi?product=librsvg
(I can do that for you, I have an account in GNOME's bugzilla, just
let me know if you want)
I am one of those who really want and need SVG support in E. I am
using EFM and I'm often browsing the dirs with my vector
Carsten Haitzler (The Rasterman) wrote:
unfortunately - we have issues like fdo menus and icon specs that REQUIRE svg
support... :(:(:( big problems :( i could do something like fork of a child
process that converts via a pipe - at least if it dies the parent won't, and
we
will hit a
On Tue, 06 Mar 2007 09:57:55 -0500 dan sinclair [EMAIL PROTECTED] babbled:
Carsten Haitzler (The Rasterman) wrote:
unfortunately - we have issues like fdo menus and icon specs that REQUIRE
svg support... :(:(:( big problems :( i could do something like fork of a
child process that
On Tuesday, 06 March 2007, at 07:57:19 (+),
[EMAIL PROTECTED] wrote:
Unfortunately, SVG is here and many want it. librsvg is probably the
'best' way to go about this right now.
*sigh* Same as gettext. It's like...wait for it...wait for it...
Deja GNU.
However, there's no reason why
On Tuesday, 06 March 2007, at 19:41:59 (+0900),
Carsten Haitzler wrote:
ooh no - i didn't actually fix any leak. i added the close call
HOPING it'd fix the leak - it didn't.
Ah, okay. I misunderstood then.
but it doesn't make me feel any better about the quality of the code
for what is not
On Monday, 05 March 2007, at 13:19:49 (-0500),
Enlightenment CVS wrote:
ok- disable the close - seems librsvg in some versions is so buggy
you can't close it to prevent leaks!
Sounds like it's time to stop using it.
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL
On Mon, 5 Mar 2007 11:37:59 -0500 Michael Jennings [EMAIL PROTECTED] babbled:
On Monday, 05 March 2007, at 13:19:49 (-0500),
Enlightenment CVS wrote:
ok- disable the close - seems librsvg in some versions is so buggy
you can't close it to prevent leaks!
Sounds like it's time to stop
On Tuesday, 06 March 2007, at 08:40:28 (+0900),
Carsten Haitzler wrote:
Sounds like it's time to stop using it.
--disable-svg :)
I meant in general. :)
seriously. librsvg has some issues. severe ones.
Is there a better library for SVG? Or are we once again stuck using
the script
Sounds like it's time to stop using it.
Well, that's probably too drastic. It's still really an
optionally compiled, loadable module, and raster's last mods seem
to have fixed the issues... (maybe, hopefully).
I just took a quick look at this myself, and it was really
my
On Tuesday, 06 March 2007, at 05:06:04 (+),
[EMAIL PROTECTED] wrote:
Well, that's probably too drastic. It's still really an
optionally compiled, loadable module, and raster's last mods seem
to have fixed the issues... (maybe, hopefully).
Re-enabling the leak to stop the crash is
On Mon, 5 Mar 2007, Michael Jennings wrote:
Is there a better library for SVG?
Carl Worth has written a small lib (libsvg) for cairo. It was a fork of
librsvg, without the unneeded stuff. He also thought that libsvg could be
used in librsvg. But as librsvg added support for cairo, he
Well, that's probably too drastic. It's still really an
optionally compiled, loadable module, and raster's last mods seem
to have fixed the issues... (maybe, hopefully).
Re-enabling the leak to stop the crash is not fixing the issues.
In any case, I think it would be unwise to
On Wed, 1 Nov 2006 07:56:12 -0500 (EST),
Enlightenment CVS [EMAIL PROTECTED] wrote :
Enlightenment CVS committal
Author : raster
Project : e17
Module : libs/evas
Dir : e17/libs/evas/src/lib/engines/common
Modified Files:
evas_font_main.c
Log Message:
evas
On 8/17/06, Enlightenment CVS [EMAIL PROTECTED] wrote:
-SUBDIRS = $(edb_subdir) $(eet_subdir) $(gif_subdir) $(jpeg_subdir)
$(png_subdir) $(tiff_subdir) $(xpm_subdir)
+if BUILD_LOADER_SVG
+xvg_subdir = svg
Is this a typo ? Wouldn't it be svg_loader = svg ?
+endif
+
+SUBDIRS =
On Thu, 17 Aug 2006 16:30:27 +0200 Bertrand Jacquin [EMAIL PROTECTED]
babbled:
On 8/17/06, Enlightenment CVS [EMAIL PROTECTED] wrote:
-SUBDIRS = $(edb_subdir) $(eet_subdir) $(gif_subdir) $(jpeg_subdir)
$(png_subdir) $(tiff_subdir) $(xpm_subdir) +if BUILD_LOADER_SVG
+xvg_subdir = svg
Is
54 matches
Mail list logo
