Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/software_x11
svn b0rker!
There is no evas_x_egl.h.
Daniel Juyung Seo (SeoZ)
On Tue, Sep 25, 2012 at 2:44 PM, Enlightenment SVN
wrote:
> Log:
> this is the start of something inteteresting. it is the start of using
> egl with software rendering only (no gl just egl). ie get access to
> buffer and do swaps etc. etc. etc. it's meant to be totally dynamic -
> ie dlopen libEGL if u have it and then start checking if it can do
> this thing so it doesnt add any dependencies at all.
>
>
>
> Author: raster
> Date: 2012-09-24 22:44:43 -0700 (Mon, 24 Sep 2012)
> New Revision: 77043
> Trac: http://trac.enlightenment.org/e/changeset/77043
>
> Added:
> trunk/evas/src/modules/engines/software_x11/evas_x_egl.c
> Modified:
> trunk/evas/src/modules/engines/software_x11/Makefile.am
> trunk/evas/src/modules/engines/software_x11/evas_engine.c
>
> Modified: trunk/evas/src/modules/engines/software_x11/Makefile.am
> ===
> --- trunk/evas/src/modules/engines/software_x11/Makefile.am 2012-09-25
> 03:11:21 UTC (rev 77042)
> +++ trunk/evas/src/modules/engines/software_x11/Makefile.am 2012-09-25
> 05:44:43 UTC (rev 77043)
> @@ -3,7 +3,9 @@
>
> if BUILD_ENGINE_SOFTWARE_X11
>
> -SOFTWARE_X11_SOURCES = evas_engine.c
> +SOFTWARE_X11_SOURCES = \
> +evas_engine.c \
> +evas_x_egl.c
>
> if BUILD_ENGINE_SOFTWARE_XLIB
>
> @@ -25,7 +27,7 @@
> evas_xlib_color.c \
> evas_xlib_main.c
>
> -SOFTWARE_X11_LIBADD = @FREETYPE_LIBS@ @EVAS_GENERAL_LIBS@
> @evas_engine_software_xlib_libs@
> +SOFTWARE_X11_LIBADD = @FREETYPE_LIBS@ @EVAS_GENERAL_LIBS@
> @evas_engine_software_xlib_libs@ @dlopen_libs@
>
> endif
>
> @@ -49,7 +51,7 @@
> evas_xcb_color.c \
> evas_xcb_main.c
>
> -SOFTWARE_X11_LIBADD = @FREETYPE_LIBS@ @PIXMAN_LIBS@ @EVAS_GENERAL_LIBS@
> @evas_engine_software_xcb_libs@
> +SOFTWARE_X11_LIBADD = @FREETYPE_LIBS@ @PIXMAN_LIBS@ @EVAS_GENERAL_LIBS@
> @evas_engine_software_xcb_libs@ @dlopen_libs@
>
> endif
>
>
> Modified: trunk/evas/src/modules/engines/software_x11/evas_engine.c
> ===
> --- trunk/evas/src/modules/engines/software_x11/evas_engine.c 2012-09-25
> 03:11:21 UTC (rev 77042)
> +++ trunk/evas/src/modules/engines/software_x11/evas_engine.c 2012-09-25
> 05:44:43 UTC (rev 77043)
> @@ -15,6 +15,8 @@
> # include "evas_xcb_xdefaults.h"
> #endif
>
> +#include "evas_x_egl.h"
> +
> int _evas_engine_soft_x11_log_dom = -1;
>
> /* function tables - filled in later (func and parent func) */
> @@ -63,7 +65,39 @@
> /* internal engine routines */
>
> #ifdef BUILD_ENGINE_SOFTWARE_XLIB
> +
> static void *
> +_output_egl_setup(int w, int h, int rot, Display *disp, Drawable draw,
> + Visual *vis, Colormap cmap, int depth, int debug,
> + int grayscale, int max_colors, Pixmap mask,
> + int shape_dither, int destination_alpha)
> +{
> + Render_Engine *re;
> +
> + if (!(re = calloc(1, sizeof(Render_Engine return NULL;
> + // _egl_x_disp_get()
> + // then
> + // _egl_x_disp_init()
> + // then
> + // _egl_x_disp_choose_config()
> + // then
> + // _egl_x_win_surf_new()
> + //
> + // and on cleaup
> + //
> + // _egl_x_win_surf_free()
> + //
> + // to access pixels
> + //
> + // _egl_x_map_surf()
> + //
> + // to give back pixels
> + //
> + // _egl_x_unmap_surf()
> + return re;
> +}
> +
> +static void *
> _output_xlib_setup(int w, int h, int rot, Display *disp, Drawable draw,
> Visual *vis, Colormap cmap, int depth, int debug,
> int grayscale, int max_colors, Pixmap mask,
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
Awesome information. On Sun, Aug 12, 2012 at 2:13 PM, Carsten Haitzler wrote: > On Sun, 12 Aug 2012 01:27:21 -0300 Gustavo Sverzut Barbieri > said: > > > On Sun, Aug 12, 2012 at 1:17 AM, Enlightenment SVN > > wrote: > > > so memcpy changed behavior, though within specs of the manual page > > > anyway, but now the values can be ones that break the simple > assignment. > > > > there was a long discussion about this and MySQL or Kernel, I don't > > recall which one it was, but was the same reason :-P > > how interesting... > > resulted in a vulnerability n mysql: > > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2122 > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 12 Aug 2012 01:27:21 -0300 Gustavo Sverzut Barbieri said: > On Sun, Aug 12, 2012 at 1:17 AM, Enlightenment SVN > wrote: > > so memcpy changed behavior, though within specs of the manual page > > anyway, but now the values can be ones that break the simple assignment. > > there was a long discussion about this and MySQL or Kernel, I don't > recall which one it was, but was the same reason :-P how interesting... resulted in a vulnerability n mysql: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-2122 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, Aug 12, 2012 at 1:17 AM, Enlightenment SVN wrote: > Log: > finally found evas_map weirdness bug. CEDRIC code...! commit #74180. > > now here's the rub. from the glibc manual page: > > ... > int memcmp(const void *s1, const void *s2, size_t n); > > DESCRIPTION > The memcmp() function compares the first n bytes (each interpreted > as > unsigned char) of the memory areas s1 and s2. It returns an > integer > less than, equal to, or greater than zero if s1 is found, > respectively, > to be less than, to match, or be greater than s2. > > RETURN VALUE > The memcmp() function returns an integer less than, equal to, > or > greater than zero if the first n bytes of s1 is found, respectively, > to > be less than, to match, or be greater than the first n bytes of s2. > > ... > > this explicitly says that s1 and s2 have their BYTES compared... and > then returns just some value < 0, 0 or > 0 based on the difference. what > that value is and means is not defined, as long as it is < 0, 0 or > 0. > > so the C standard has this to say: > > 6.3.1.3 Signed and unsigned integers > > 2. Otherwise, if the new type is unsigned, the value is converted by > repeatedly adding or subtracting one more than the maximum value that > can be represented in the new type until the value is in the range of > the new type. > > so a result of -255 (possible) is converted by REPEATEDLY adding the > max size of the new type (255) until within range... so ... > -255 + 255 = 0 ... within range.. BUT FALSE! > > so why do we see this now? something changed in memcpy behavior. > before we ONLY saw values of -1, 0 or 1 - nothing else, NOW we see > thins like: > > -12288 > 49152 > 4096 > 16384 > 61440 > -53248 > > so memcpy changed behavior, though within specs of the manual page > anyway, but now the values can be ones that break the simple assignment. there was a long discussion about this and MySQL or Kernel, I don't recall which one it was, but was the same reason :-P -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/bin
On Mon, 9 Jul 2012 23:54:46 -0300 Gustavo Sverzut Barbieri
said:
> Okay in this case because we know the whole thing, but if this went in a
> lib it would be racy and allows fds to leak to child processes.
actually it'd only be racy *IF* u have the ability to call back to app between
accept() and fcntl() so it might fork a child in that time *OR* if this was run
from a thread and then u have a race with the mainloop forking at the exact
time between accept and fcntl. that's it. :) one of the good reasons to be very
careful about how we support threaded usage and support.
> On Monday, July 9, 2012, Enlightenment SVN wrote:
>
> > Log:
> > use extra fcntl() instead of accept4 for portability.
> >
> >
> >
> > Author: raster
> > Date: 2012-07-09 19:35:00 -0700 (Mon, 09 Jul 2012)
> > New Revision: 73509
> > Trac: http://trac.enlightenment.org/e/changeset/73509
> >
> > Modified:
> > trunk/evas/src/bin/evas_cserve2_main_loop_linux.c
> >
> > Modified: trunk/evas/src/bin/evas_cserve2_main_loop_linux.c
> > ===
> > --- trunk/evas/src/bin/evas_cserve2_main_loop_linux.c 2012-07-09
> > 19:52:58 UTC (rev 73508)
> > +++ trunk/evas/src/bin/evas_cserve2_main_loop_linux.c 2012-07-10
> > 02:35:00 UTC (rev 73509)
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define MAX_EPOLL_EVENTS 10
> > #define MAX_INCOMING_CONN 10
> > @@ -186,12 +187,13 @@
> > int s;
> >
> > len = sizeof(struct sockaddr_un);
> > - s = accept4(socket_fd, &remote, &len, SOCK_CLOEXEC);
> > + s = accept(socket_fd, &remote, &len);
> > if (s == -1)
> > {
> > ERR("Could not accept socket: \"%s\"", strerror(errno));
> > return;
> > }
> > + fcntl(s, F_SETFD, FD_CLOEXEC);
> >
> > cserve2_client_accept(s);
> > }
> >
> >
> >
> > --
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/bin
Okay in this case because we know the whole thing, but if this went in a
lib it would be racy and allows fds to leak to child processes.
On Monday, July 9, 2012, Enlightenment SVN wrote:
> Log:
> use extra fcntl() instead of accept4 for portability.
>
>
>
> Author: raster
> Date: 2012-07-09 19:35:00 -0700 (Mon, 09 Jul 2012)
> New Revision: 73509
> Trac: http://trac.enlightenment.org/e/changeset/73509
>
> Modified:
> trunk/evas/src/bin/evas_cserve2_main_loop_linux.c
>
> Modified: trunk/evas/src/bin/evas_cserve2_main_loop_linux.c
> ===
> --- trunk/evas/src/bin/evas_cserve2_main_loop_linux.c 2012-07-09
> 19:52:58 UTC (rev 73508)
> +++ trunk/evas/src/bin/evas_cserve2_main_loop_linux.c 2012-07-10
> 02:35:00 UTC (rev 73509)
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #define MAX_EPOLL_EVENTS 10
> #define MAX_INCOMING_CONN 10
> @@ -186,12 +187,13 @@
> int s;
>
> len = sizeof(struct sockaddr_un);
> - s = accept4(socket_fd, &remote, &len, SOCK_CLOEXEC);
> + s = accept(socket_fd, &remote, &len);
> if (s == -1)
> {
> ERR("Could not accept socket: \"%s\"", strerror(errno));
> return;
> }
> + fcntl(s, F_SETFD, FD_CLOEXEC);
>
> cserve2_client_accept(s);
> }
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/engines/common
On Thu, Jun 21, 2012 at 4:26 PM, Gustavo Sverzut Barbieri wrote: >>> @@ -498,6 +533,22 @@ >>> #ifdef HAVE_PTHREAD >>> // pthread_mutex_unlock(&fi->ft_mutex); >>> #endif >> >> are you sure that you don't have to use macro LK*** instead of >> directly pthread (i fear a big problem on windows...) > > drogs?! he used the macros in his code, that one is context, was already there drugs, indeed. I didn't see the //, I focalized on the pthread_** code. Vincent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/engines/common
On Thu, Jun 21, 2012 at 10:57 AM, Vincent Torri wrote:
> On Thu, Jun 21, 2012 at 3:48 PM, Enlightenment SVN
> wrote:
>> Log:
>> tenative font glyph workaround for fonts not containing gfx drawing
>> chars.
>>
>>
>>
>> Author: raster
>> Date: 2012-06-21 06:48:59 -0700 (Thu, 21 Jun 2012)
>> New Revision: 72604
>> Trac: http://trac.enlightenment.org/e/changeset/72604
>>
>> Modified:
>> trunk/evas/src/lib/engines/common/evas_font_main.c
>>
>> Modified: trunk/evas/src/lib/engines/common/evas_font_main.c
>> ===
>> --- trunk/evas/src/lib/engines/common/evas_font_main.c 2012-06-21 13:45:36
>> UTC (rev 72603)
>> +++ trunk/evas/src/lib/engines/common/evas_font_main.c 2012-06-21 13:48:59
>> UTC (rev 72604)
>> @@ -366,7 +366,6 @@
>> if (fg == (void *)(-1)) return NULL;
>> else if (fg) return fg;
>> }
>> -
>> // fg = eina_hash_find(fi->glyphs, &hindex);
>> // if (fg) return fg;
>>
>> @@ -467,6 +466,42 @@
>> EAPI FT_UInt
>> evas_common_get_char_index(RGBA_Font_Int* fi, Eina_Unicode gl)
>> {
>> + static const Eina_Unicode mapfix[] =
>> + {
>> + 0x25c6, 0x1,
>> + 0x2592, 0x2,
>> + 0x2409, 0x3,
>> + 0x240c, 0x4,
>> + 0x240d, 0x5,
>> + 0x240a, 0x6,
>> + 0x00b0, 0x7,
>> + 0x00b1, 0x8,
>> + 0x2424, 0x9,
>> + 0x240b, 0xa,
>> + 0x2518, 0xb,
>> + 0x2510, 0xc,
>> + 0x250c, 0xd,
>> + 0x2514, 0xe,
>> + 0x253c, 0xf,
>> + 0x23ba, 0x10,
>> + 0x23bb, 0x11,
>> + 0x2500, 0x12,
>> + 0x23bc, 0x13,
>> + 0x23bd, 0x14,
>> + 0x251c, 0x15,
>> + 0x2524, 0x16,
>> + 0x2534, 0x17,
>> + 0x252c, 0x18,
>> + 0x2502, 0x19,
>> + 0x2264, 0x1a,
>> + 0x2265, 0x1b,
>> + 0x03c0, 0x1c,
>> + 0x2260, 0x1d,
>> + 0x00a3, 0xa3,
>> + 0x00b7, 0x1f,
>> + 0x20a4, 0xa3,
>> + 0x, 0x0
>> + };
>> Font_Char_Index result;
>> //FT_UInt ret;
>>
>> @@ -498,6 +533,22 @@
>> #ifdef HAVE_PTHREAD
>> // pthread_mutex_unlock(&fi->ft_mutex);
>> #endif
>
> are you sure that you don't have to use macro LK*** instead of
> directly pthread (i fear a big problem on windows...)
drogs?! he used the macros in his code, that one is context, was already there
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/engines/common
On Thu, Jun 21, 2012 at 3:48 PM, Enlightenment SVN
wrote:
> Log:
> tenative font glyph workaround for fonts not containing gfx drawing
> chars.
>
>
>
> Author: raster
> Date: 2012-06-21 06:48:59 -0700 (Thu, 21 Jun 2012)
> New Revision: 72604
> Trac: http://trac.enlightenment.org/e/changeset/72604
>
> Modified:
> trunk/evas/src/lib/engines/common/evas_font_main.c
>
> Modified: trunk/evas/src/lib/engines/common/evas_font_main.c
> ===
> --- trunk/evas/src/lib/engines/common/evas_font_main.c 2012-06-21 13:45:36
> UTC (rev 72603)
> +++ trunk/evas/src/lib/engines/common/evas_font_main.c 2012-06-21 13:48:59
> UTC (rev 72604)
> @@ -366,7 +366,6 @@
> if (fg == (void *)(-1)) return NULL;
> else if (fg) return fg;
> }
> -
> // fg = eina_hash_find(fi->glyphs, &hindex);
> // if (fg) return fg;
>
> @@ -467,6 +466,42 @@
> EAPI FT_UInt
> evas_common_get_char_index(RGBA_Font_Int* fi, Eina_Unicode gl)
> {
> + static const Eina_Unicode mapfix[] =
> + {
> + 0x25c6, 0x1,
> + 0x2592, 0x2,
> + 0x2409, 0x3,
> + 0x240c, 0x4,
> + 0x240d, 0x5,
> + 0x240a, 0x6,
> + 0x00b0, 0x7,
> + 0x00b1, 0x8,
> + 0x2424, 0x9,
> + 0x240b, 0xa,
> + 0x2518, 0xb,
> + 0x2510, 0xc,
> + 0x250c, 0xd,
> + 0x2514, 0xe,
> + 0x253c, 0xf,
> + 0x23ba, 0x10,
> + 0x23bb, 0x11,
> + 0x2500, 0x12,
> + 0x23bc, 0x13,
> + 0x23bd, 0x14,
> + 0x251c, 0x15,
> + 0x2524, 0x16,
> + 0x2534, 0x17,
> + 0x252c, 0x18,
> + 0x2502, 0x19,
> + 0x2264, 0x1a,
> + 0x2265, 0x1b,
> + 0x03c0, 0x1c,
> + 0x2260, 0x1d,
> + 0x00a3, 0xa3,
> + 0x00b7, 0x1f,
> + 0x20a4, 0xa3,
> + 0x, 0x0
> + };
> Font_Char_Index result;
> //FT_UInt ret;
>
> @@ -498,6 +533,22 @@
> #ifdef HAVE_PTHREAD
> // pthread_mutex_unlock(&fi->ft_mutex);
> #endif
are you sure that you don't have to use macro LK*** instead of
directly pthread (i fear a big problem on windows...)
Vincent
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Wed, 7 Mar 2012 17:58:48 +0100 Joerg Sonnenberger said: > On Thu, Mar 08, 2012 at 12:51:19AM +0900, Carsten Haitzler wrote: > > On Wed, 7 Mar 2012 12:37:42 -0300 Gustavo Sverzut Barbieri > > said: > > > > > On Wed, Mar 7, 2012 at 6:05 AM, Enlightenment SVN > > > wrote: > > > > Log: > > > > to be paranoid - ensure umask for mkstemp allows no other uids oir > > > > grps access. > > > > > > Ugh, isn't there any other way to do this? What you did break if > > > people are using other threads to open files, and if they fork() they > > > will inherit these values! TOO BAD :-( > > > > 1. umask is reset back immediately after creation so fork (unless its FROM > > another thread which is incredibly odd) wont be a problem > > 2. its changed for a very short period so yes - it could affect other > > threads creating files too but its a very small condition, but yes - its > > possible > > 3. no mk*temp libc funcs let u set mode so this is the only way other than > > creating our own tmpfile name allocator. > > > > NOT doing this makes for a security hole. i'd rather this very "rare/odd" > > bug than the security hole until someone spends the time to make a custom > > tmpfile creator. > > mkstemp is supposed to create the file with 0600 permission, so is that > really necessary? indeed you are right - early glibc's were 0666. shall remove then. glibc issue if they care about this. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Thu, Mar 08, 2012 at 12:51:19AM +0900, Carsten Haitzler wrote: > On Wed, 7 Mar 2012 12:37:42 -0300 Gustavo Sverzut Barbieri > said: > > > On Wed, Mar 7, 2012 at 6:05 AM, Enlightenment SVN > > wrote: > > > Log: > > > to be paranoid - ensure umask for mkstemp allows no other uids oir > > > grps access. > > > > Ugh, isn't there any other way to do this? What you did break if > > people are using other threads to open files, and if they fork() they > > will inherit these values! TOO BAD :-( > > 1. umask is reset back immediately after creation so fork (unless its FROM > another thread which is incredibly odd) wont be a problem > 2. its changed for a very short period so yes - it could affect other threads > creating files too but its a very small condition, but yes - its possible > 3. no mk*temp libc funcs let u set mode so this is the only way other than > creating our own tmpfile name allocator. > > NOT doing this makes for a security hole. i'd rather this very "rare/odd" bug > than the security hole until someone spends the time to make a custom tmpfile > creator. mkstemp is supposed to create the file with 0600 permission, so is that really necessary? Joerg -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Wed, 7 Mar 2012 12:37:42 -0300 Gustavo Sverzut Barbieri said: > On Wed, Mar 7, 2012 at 6:05 AM, Enlightenment SVN > wrote: > > Log: > > to be paranoid - ensure umask for mkstemp allows no other uids oir > > grps access. > > Ugh, isn't there any other way to do this? What you did break if > people are using other threads to open files, and if they fork() they > will inherit these values! TOO BAD :-( 1. umask is reset back immediately after creation so fork (unless its FROM another thread which is incredibly odd) wont be a problem 2. its changed for a very short period so yes - it could affect other threads creating files too but its a very small condition, but yes - its possible 3. no mk*temp libc funcs let u set mode so this is the only way other than creating our own tmpfile name allocator. NOT doing this makes for a security hole. i'd rather this very "rare/odd" bug than the security hole until someone spends the time to make a custom tmpfile creator. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Wed, Mar 7, 2012 at 6:05 AM, Enlightenment SVN wrote: > Log: > to be paranoid - ensure umask for mkstemp allows no other uids oir > grps access. Ugh, isn't there any other way to do this? What you did break if people are using other threads to open files, and if they fork() they will inherit these values! TOO BAD :-( -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Thu, 23 Feb 2012 13:51:47 -0200 Gustavo Sverzut Barbieri said: > On Thu, Feb 23, 2012 at 2:53 AM, Enlightenment SVN > wrote: > > Log: > > since too many people make this mistake of not reading evas's docs and > > seeing color is PREMULTIPLIED ARGB... evas_object_color_set is just > > going to enforce it and limit r, g and b to a. > > I always wondered why it did not do that. > > But please issue a warning as well, since you're just resetting the > color instead of properly fix the color to be premultiplied (ie: > a=128, r=200, g=255, b=129 will become a = r = g = b = 128 with your > code). i was going to put in an abort() instead. :) seriously. thats the code i had typed up before i changed it. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Thu, Feb 23, 2012 at 2:53 AM, Enlightenment SVN wrote: > Log: > since too many people make this mistake of not reading evas's docs and > seeing color is PREMULTIPLIED ARGB... evas_object_color_set is just > going to enforce it and limit r, g and b to a. I always wondered why it did not do that. But please issue a warning as well, since you're just resetting the color instead of properly fix the color to be premultiplied (ie: a=128, r=200, g=255, b=129 will become a = r = g = b = 128 with your code). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Fri, 30 Dec 2011 16:40:42 +0100 Cedric BAIL said:
> On Fri, Dec 30, 2011 at 4:20 PM, Enlightenment SVN
> wrote:
> > Log:
> > fix mouse out handler to out all objects mouse is in - right thing to
> > do.
>
> I see some resizing issue in E17 where mouse out seems to be ignored
> or something like that.
yeah. it's fix 1 bug, create a onther. e17 has some really old crusty code
where it does weird things with border events. fixed now. :)
> > Author: raster
> > Date: 2011-12-30 07:20:15 -0800 (Fri, 30 Dec 2011)
> > New Revision: 66699
> > Trac: http://trac.enlightenment.org/e/changeset/66699
> >
> > Modified:
> > trunk/evas/src/lib/canvas/evas_events.c
> >
> > Modified: trunk/evas/src/lib/canvas/evas_events.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_events.c 2011-12-30 15:17:13 UTC
> > (rev 66698) +++ trunk/evas/src/lib/canvas/evas_events.c 2011-12-30
> > 15:20:15 UTC (rev 66699) @@ -909,8 +909,7 @@
> > ev.event_flags = e->default_event_flags;
> >
> > _evas_walk(e);
> > - /* if our mouse button is grabbed to any objects */
> > - if ((0) && (e->pointer.mouse_grabbed != 0))
> > + /* if our mouse button is inside any objects */
> > {
> > /* go thru old list of in objects */
> > Eina_List *l, *copy;
> > @@ -928,7 +927,7 @@
> > if (!obj->delete_me)
> > {
> > if (e->events_frozen <= 0)
> > - evas_object_event_callback_call(obj,
> > EVAS_CALLBACK_MOUSE_OUT, &ev, event_id);
> > + evas_object_event_callback_call(obj,
> > EVAS_CALLBACK_MOUSE_OUT, &ev, event_id); }
> > obj->mouse_grabbed = 0;
> > }
> >
> >
> > --
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > infrastructure or vast IT resources to deliver seamless, secure access to
> > virtual desktops. With this all-in-one solution, easily deploy virtual
> > desktops for less than the cost of PCs and save 60% on VDI infrastructure
> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
>
>
>
> --
> Cedric BAIL
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Fri, Dec 30, 2011 at 4:20 PM, Enlightenment SVN
wrote:
> Log:
> fix mouse out handler to out all objects mouse is in - right thing to
> do.
I see some resizing issue in E17 where mouse out seems to be ignored
or something like that.
> Author: raster
> Date: 2011-12-30 07:20:15 -0800 (Fri, 30 Dec 2011)
> New Revision: 66699
> Trac: http://trac.enlightenment.org/e/changeset/66699
>
> Modified:
> trunk/evas/src/lib/canvas/evas_events.c
>
> Modified: trunk/evas/src/lib/canvas/evas_events.c
> ===
> --- trunk/evas/src/lib/canvas/evas_events.c 2011-12-30 15:17:13 UTC (rev
> 66698)
> +++ trunk/evas/src/lib/canvas/evas_events.c 2011-12-30 15:20:15 UTC (rev
> 66699)
> @@ -909,8 +909,7 @@
> ev.event_flags = e->default_event_flags;
>
> _evas_walk(e);
> - /* if our mouse button is grabbed to any objects */
> - if ((0) && (e->pointer.mouse_grabbed != 0))
> + /* if our mouse button is inside any objects */
> {
> /* go thru old list of in objects */
> Eina_List *l, *copy;
> @@ -928,7 +927,7 @@
> if (!obj->delete_me)
> {
> if (e->events_frozen <= 0)
> - evas_object_event_callback_call(obj,
> EVAS_CALLBACK_MOUSE_OUT, &ev, event_id);
> + evas_object_event_callback_call(obj,
> EVAS_CALLBACK_MOUSE_OUT, &ev, event_id);
> }
> obj->mouse_grabbed = 0;
> }
>
>
> --
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
Cedric BAIL
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sunday, October 23, 2011, Carsten Haitzler wrote: > On Sun, 23 Oct 2011 11:17:25 -0200 Gustavo Sverzut Barbieri > said: > >> It is funny to see every 6 months or so... I gave up on trying because since >> 2007 when I started we have a common blocker thing: raster. He is the single > > and every time this comes up i say "someone go find a formatter that > consistently format in a way close if not exactly how things are done now". the > only person who seriously did anything is mike! you, instead just choose to > whine like a broken record. i gave a path to solve this. it's not quite there > yet. It wont help to just find a tool :-) >> thing that will block this, his editor does not have such a thing and nobody > > OMG! OMG! i'm not in the vim user club! oh i'm such a loser! i'm not in the vim > user club and i don't care. i suggest you adjust your attitude or take it and > yourself elsewhere Btw, I'm an emacs user. We have both clubs here! >> will make him change his editor and he is the one doing most of the code >> (and will remain like that forever as his attitude doesn't help to attract >> more dudes) > > now you want to begin making it personal? fine. let's see how well that works > out. > >> So just ignore white spaces and br happy ;-) As I said, just ignore and be happy ;-) >> >> On Sunday, October 23, 2011, Lucas De Marchi < lucas.demar...@profusion.mobi> >> wrote: >> > On Sun, Oct 23, 2011 at 5:56 AM, Carsten Haitzler >> wrote: >> >> On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo < >> seojuyu...@gmail.com> >> >> said: >> >> >> >> i see my test worked. the irrational formatting pedants now come out of >> the >> >> woodwork. i did this to see just who would respond and how. >> >> >> >> i added spaces on BLANK LINES that align with indenting. all it takes is >> an >> >> enter or hitting tab. all editors do this by default (with autoindent >> on). >> > >> > All decent editors have an option to configure this. It's not a >> > matter of fighting the editor, but correctly configuring it. >> > >> > Can you look at the diff you generated and sanely review it with the >> > bunch of line changes that are totally unrelated? >> > >> >> >> >> are these pedants (like you and vincent) proposing that we fight against >> our >> >> editors and keep undoing the work they do for us? i assume the answer is >> yes >> >> because this whole thing is irrational. >> > >> > Do you really think all the other decent open source projects out >> > there have pedant developers/maintainers? >> > >> > >> > Lucas De Marchi >> > >> > >> -- >> > The demand for IT networking professionals continues to grow, and the >> > demand for specialized networking skills is growing even more rapidly. >> > Take a complimentary Learning@Cisco Self-Assessment and learn >> > about Cisco certifications, training, and career opportunities. >> > http://p.sf.net/sfu/cisco-dev2dev >> > ___ >> > enlightenment-devel mailing list >> > enlightenment-devel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >> >> -- >> Gustavo Sverzut Barbieri >> http://profusion.mobi embedded systems >> -- >> MSN: barbi...@gmail.com >> Skype: gsbarbieri >> Mobile: +55 (19) 9225-2202 >> -- >> The demand for IT networking professionals continues to grow, and the >> demand for specialized networking skills is growing even more rapidly. >> Take a complimentary Learning@Cisco Self-Assessment and learn >> about Cisco certifications, training, and career opportunities. >> http://p.sf.net/sfu/cisco-dev2dev >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 23 Oct 2011 10:55:13 -0200 Lucas De Marchi said: > On Sun, Oct 23, 2011 at 5:56 AM, Carsten Haitzler > wrote: > > On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo > > said: > > > > i see my test worked. the irrational formatting pedants now come out of the > > woodwork. i did this to see just who would respond and how. > > > > i added spaces on BLANK LINES that align with indenting. all it takes is an > > enter or hitting tab. all editors do this by default (with autoindent on). > > All decent editors have an option to configure this. It's not a > matter of fighting the editor, but correctly configuring it. > > Can you look at the diff you generated and sanely review it with the > bunch of line changes that are totally unrelated? you don't get it. that commit was a troll. specifically to set off all the "omg whitespace at the end of a line!" brigade. it has worked a charm. > > > > are these pedants (like you and vincent) proposing that we fight against our > > editors and keep undoing the work they do for us? i assume the answer is yes > > because this whole thing is irrational. > > Do you really think all the other decent open source projects out > there have pedant developers/maintainers? well funny - i'm not as pedantic. this is the "how dare your editor not do what mine is doing" brigade. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 23 Oct 2011 11:17:25 -0200 Gustavo Sverzut Barbieri said: > It is funny to see every 6 months or so... I gave up on trying because since > 2007 when I started we have a common blocker thing: raster. He is the single and every time this comes up i say "someone go find a formatter that consistently format in a way close if not exactly how things are done now". the only person who seriously did anything is mike! you, instead just choose to whine like a broken record. i gave a path to solve this. it's not quite there yet. > thing that will block this, his editor does not have such a thing and nobody OMG! OMG! i'm not in the vim user club! oh i'm such a loser! i'm not in the vim user club and i don't care. i suggest you adjust your attitude or take it and yourself elsewhere > will make him change his editor and he is the one doing most of the code > (and will remain like that forever as his attitude doesn't help to attract > more dudes) now you want to begin making it personal? fine. let's see how well that works out. > So just ignore white spaces and br happy ;-) > > On Sunday, October 23, 2011, Lucas De Marchi > wrote: > > On Sun, Oct 23, 2011 at 5:56 AM, Carsten Haitzler > wrote: > >> On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo < > seojuyu...@gmail.com> > >> said: > >> > >> i see my test worked. the irrational formatting pedants now come out of > the > >> woodwork. i did this to see just who would respond and how. > >> > >> i added spaces on BLANK LINES that align with indenting. all it takes is > an > >> enter or hitting tab. all editors do this by default (with autoindent > on). > > > > All decent editors have an option to configure this. It's not a > > matter of fighting the editor, but correctly configuring it. > > > > Can you look at the diff you generated and sanely review it with the > > bunch of line changes that are totally unrelated? > > > >> > >> are these pedants (like you and vincent) proposing that we fight against > our > >> editors and keep undoing the work they do for us? i assume the answer is > yes > >> because this whole thing is irrational. > > > > Do you really think all the other decent open source projects out > > there have pedant developers/maintainers? > > > > > > Lucas De Marchi > > > > > -- > > The demand for IT networking professionals continues to grow, and the > > demand for specialized networking skills is growing even more rapidly. > > Take a complimentary Learning@Cisco Self-Assessment and learn > > about Cisco certifications, training, and career opportunities. > > http://p.sf.net/sfu/cisco-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
It is funny to see every 6 months or so... I gave up on trying because since 2007 when I started we have a common blocker thing: raster. He is the single thing that will block this, his editor does not have such a thing and nobody will make him change his editor and he is the one doing most of the code (and will remain like that forever as his attitude doesn't help to attract more dudes) So just ignore white spaces and br happy ;-) On Sunday, October 23, 2011, Lucas De Marchi wrote: > On Sun, Oct 23, 2011 at 5:56 AM, Carsten Haitzler wrote: >> On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo < seojuyu...@gmail.com> >> said: >> >> i see my test worked. the irrational formatting pedants now come out of the >> woodwork. i did this to see just who would respond and how. >> >> i added spaces on BLANK LINES that align with indenting. all it takes is an >> enter or hitting tab. all editors do this by default (with autoindent on). > > All decent editors have an option to configure this. It's not a > matter of fighting the editor, but correctly configuring it. > > Can you look at the diff you generated and sanely review it with the > bunch of line changes that are totally unrelated? > >> >> are these pedants (like you and vincent) proposing that we fight against our >> editors and keep undoing the work they do for us? i assume the answer is yes >> because this whole thing is irrational. > > Do you really think all the other decent open source projects out > there have pedant developers/maintainers? > > > Lucas De Marchi > > -- > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, Oct 23, 2011 at 5:56 AM, Carsten Haitzler wrote: > On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo > said: > > i see my test worked. the irrational formatting pedants now come out of the > woodwork. i did this to see just who would respond and how. > > i added spaces on BLANK LINES that align with indenting. all it takes is an > enter or hitting tab. all editors do this by default (with autoindent on). All decent editors have an option to configure this. It's not a matter of fighting the editor, but correctly configuring it. Can you look at the diff you generated and sanely review it with the bunch of line changes that are totally unrelated? > > are these pedants (like you and vincent) proposing that we fight against our > editors and keep undoing the work they do for us? i assume the answer is yes > because this whole thing is irrational. Do you really think all the other decent open source projects out there have pedant developers/maintainers? Lucas De Marchi -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 23 Oct 2011 10:00:49 +0200 (CEST) Vincent Torri
said:
>
>
> On Sun, 23 Oct 2011, Carsten Haitzler (The Rasterman) wrote:
>
> > On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo
> > said:
> >
> > i see my test worked. the irrational formatting pedants now come out of the
> > woodwork. i did this to see just who would respond and how.
> >
> > i added spaces on BLANK LINES that align with indenting. all it takes is an
> > enter or hitting tab. all editors do this by default (with autoindent on).
> >
> > are these pedants (like you and vincent) proposing that we fight against our
> > editors and keep undoing the work they do for us? i assume the answer is yes
> > because this whole thing is irrational.
>
> no : the parsing fo the files is faster without these white spaces, so
> it's not illogical :p
BWHAHAHAHAHAHAHAHHAHAH! hehehehe... well played! touché!
:)
> >
> >> Well... This is my personal opinion about this commit.
> >> This is so disappointing and childish as a grown-up person.
> >>
> >> I didn't set that vim configuration before I was requested to remove
> >> trailing whitespaces from enlightenment community.
> >> Now e-founder encourages trailing whitespaces.
> >> Seriously that's so funny.
> >>
> >> Anyhow, I have no objection to you doing this funny behavior because
> >> it looks like trailing whitespace is now allowed in enlightenment.
> >>
> >> Thanks.
> >>
> >> Daniel Juyung Seo (SeoZ)
> >>
> >> On Sun, Oct 23, 2011 at 12:51 PM, Enlightenment SVN
> >> wrote:
> >>> Log:
> >>> annoy vim users with spaces at the start of blank lines. :)
> >>>
> >>>
> >>>
> >>> Author: raster
> >>> Date: 2011-10-22 20:51:41 -0700 (Sat, 22 Oct 2011)
> >>> New Revision: 64317
> >>> Trac: http://trac.enlightenment.org/e/changeset/64317
> >>>
> >>> Modified:
> >>> trunk/evas/src/lib/canvas/evas_async_events.c
> >>>
> >>> Modified: trunk/evas/src/lib/canvas/evas_async_events.c
> >>> ===
> >>> --- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-22
> >>> 23:40:48 UTC (rev 64316) +++ trunk/evas/src/lib/canvas/evas_async_events.c
> >>> 2011-10-23 03:51:41 UTC (rev 64317) @@ -3,11 +3,11 @@
> >>>
> >>> #ifdef BUILD_ASYNC_EVENTS
> >>>
> >>> -#ifndef _MSC_VER
> >>> -# include
> >>> -#endif
> >>> -#include
> >>> -#include
> >>> +# ifndef _MSC_VER
> >>> +# include
> >>> +# endif
> >>> +# include
> >>> +# include
> >>>
> >>> static int _fd_write = -1;
> >>> static int _fd_read = -1;
> >>> @@ -28,21 +28,21 @@
> >>> evas_async_events_init(void)
> >>> {
> >>> int filedes[2];
> >>> -
> >>> +
> >>> _init_evas_event++;
> >>> if (_init_evas_event > 1) return _init_evas_event;
> >>> -
> >>> +
> >>> if (pipe(filedes) == -1)
> >>> {
> >>> _init_evas_event = 0;
> >>> return 0;
> >>> }
> >>> -
> >>> +
> >>> _fd_read = filedes[0];
> >>> _fd_write = filedes[1];
> >>> -
> >>> +
> >>> fcntl(_fd_read, F_SETFL, O_NONBLOCK);
> >>> -
> >>> +
> >>> return _init_evas_event;
> >>> }
> >>>
> >>> @@ -51,12 +51,12 @@
> >>> {
> >>> _init_evas_event--;
> >>> if (_init_evas_event > 0) return _init_evas_event;
> >>> -
> >>> +
> >>> close(_fd_read);
> >>> close(_fd_write);
> >>> _fd_read = -1;
> >>> _fd_write = -1;
> >>> -
> >>> +
> >>> return _init_evas_event;
> >>> }
> >>>
> >>> @@ -79,10 +79,10 @@
> >>> Evas_Event_Async *ev;
> >>> int check;
> >>> int count = 0;
> >>> -
> >>> +
> >>> if (_fd_read == -1) return 0;
> >>> -
> >>> - do
> >>> +
> >>> + do
> >>> {
> >>> check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
> >>>
> >>> @@ -92,11 +92,11 @@
> >>> free(ev);
> >>> count++;
> >>> }
> >>> - }
> >>> + }
> >>> while (check > 0);
> >>> -
> >>> +
> >>> evas_cache_image_wakeup();
> >>> -
> >>> +
> >>> if (check < 0)
> >>> {
> >>> switch (errno)
> >>> @@ -108,7 +108,7 @@
> >>> _fd_read = -1;
> >>> }
> >>> }
> >>> -
> >>> +
> >>> return count;
> >>> #else
> >>> return 0;
> >>> @@ -122,27 +122,27 @@
> >>> Evas_Event_Async *ev;
> >>> ssize_t check;
> >>> Eina_Bool result = EINA_FALSE;
> >>> -
> >>> +
> >>> if (!func) return 0;
> >>> if (_fd_write == -1) return 0;
> >>> -
> >>> +
> >>> ev = calloc(1, sizeof (Evas_Event_Async));
> >>> if (!ev) return 0;
> >>> -
> >>> +
> >>> ev->func = func;
> >>> ev->target = target;
> >>> ev->type = type;
> >>> ev->event_info = event_info;
> >>> -
> >>> - do
> >>> +
> >>> + do
> >>> {
> >>> check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> >>> }
> >>> - while ((check != sizeof (Evas_Event_Async*)) &&
> >>> + while ((check != sizeof (Evas_Event_Async*)) &&
> >>> ((errno == EINTR) || (errno == EAGAIN)));
> >>> -
> >>> +
> >>> evas_cache_image_wakeup();
> >>> -
> >>> +
> >>> if (check == sizeof (Evas_Event_Async*))
> >>>
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On 23/10/11 10:24, Mike Blumenkrantz wrote: > On Sun, 23 Oct 2011 10:22:02 +0200 > Tom Hacohen wrote: >> Trailing whites are bad for a couple reasons, some of which are: >> * unwanted increase in source code size (it's actually noticeable, but >> hey, it's also the case with spaces vs tabs). > yeah, and unnecessary prefixing of commit messages does the same. problem? It's not unnecessary, I explained exactly why in the email I suggested it at, and I guess that's why people agreed with it. More than that, I think, and I believe that others agree, that this was a very needed and useful change, it surely made my life easier/more convenient. Furthermore, commits messages are different than source codes, making such comparison is at best a poor trolling attempt. >> * Increased likelihood of merge clashes. It's easier to miss whitespace >> changes when you don't care about them, and a lot of whites can make it >> nuts. > don't you use git which can avoid whitespace clashes? I do, but I'm not aware of any way to make git avoid whitespace clashes, but even if there is a way, there are still svn users out there. Please, if you know such a way, let me know, sounds like a useful trick. >> * Causing annoying line-wraps for no reason. (a couple of trailing whites). > use a real editor/term which doesn't have mandatory 80 character wrapping > since > we aren't in the 1960s anymore? It's part of the coding conventions, I can change it to whatever value I want in vim, but it's set as 80 cause that's what we all decided to follow (e coding conventions). Furthermore, I rather like 80, it's very useful, it lets you open a couple of instances of vim in the same window without any horizontal scrolling (or wrapping in my case). >> * People (I'm among them) just don't like trailing whites. > oh good, finally a real point. ;P >> * Some other things I can't think about atm. > stop claiming there's any reason to this besides not liking trailing > whitespaces. I don't like them, so I remove them. sometimes. to suggest > anything different is really not going to do anything but give me (and > others) some laughs. > As you can see, I stated a couple of reasons, one of which is the reason you mentioned, which holds on it's own, the others, are valid as well. I'm also against the whitespace witch-hunt, i.e going through all of svn and manually changing whitespace errors, but I'm very much against adding new errors to the code base. -- Tom. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 23 Oct 2011 10:22:02 +0200 Tom Hacohen wrote: > On 23/10/11 09:56, Carsten Haitzler (The Rasterman) wrote: > > i see my test worked. the irrational formatting pedants now come out of the > > woodwork. i did this to see just who would respond and how. > > You test was a bit biased from the start. Making the commit message this > provoking is sure to cause extreme and immediate responses. > > > > i added spaces on BLANK LINES that align with indenting. all it takes is an > > enter or hitting tab. all editors do this by default (with autoindent on). > > > > are these pedants (like you and vincent) proposing that we fight against our > > editors and keep undoing the work they do for us? i assume the answer is yes > > because this whole thing is irrational. > > Decent editors (and even less than decent ones), like vim, automatically > remove the automatic indentation when it was not used, i.e when you > don't insert code. > > Trailing whites are bad for a couple reasons, some of which are: > * unwanted increase in source code size (it's actually noticeable, but > hey, it's also the case with spaces vs tabs). yeah, and unnecessary prefixing of commit messages does the same. problem? > * Increased likelihood of merge clashes. It's easier to miss whitespace > changes when you don't care about them, and a lot of whites can make it > nuts. don't you use git which can avoid whitespace clashes? > * Causing annoying line-wraps for no reason. (a couple of trailing whites). use a real editor/term which doesn't have mandatory 80 character wrapping since we aren't in the 1960s anymore? > * People (I'm among them) just don't like trailing whites. oh good, finally a real point. > * Some other things I can't think about atm. > > -- > Tom. > > -- > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel stop claiming there's any reason to this besides not liking trailing whitespaces. I don't like them, so I remove them. sometimes. to suggest anything different is really not going to do anything but give me (and others) some laughs. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On 23/10/11 09:56, Carsten Haitzler (The Rasterman) wrote: > i see my test worked. the irrational formatting pedants now come out of the > woodwork. i did this to see just who would respond and how. You test was a bit biased from the start. Making the commit message this provoking is sure to cause extreme and immediate responses. > > i added spaces on BLANK LINES that align with indenting. all it takes is an > enter or hitting tab. all editors do this by default (with autoindent on). > > are these pedants (like you and vincent) proposing that we fight against our > editors and keep undoing the work they do for us? i assume the answer is yes > because this whole thing is irrational. Decent editors (and even less than decent ones), like vim, automatically remove the automatic indentation when it was not used, i.e when you don't insert code. Trailing whites are bad for a couple reasons, some of which are: * unwanted increase in source code size (it's actually noticeable, but hey, it's also the case with spaces vs tabs). * Increased likelihood of merge clashes. It's easier to miss whitespace changes when you don't care about them, and a lot of whites can make it nuts. * Causing annoying line-wraps for no reason. (a couple of trailing whites). * People (I'm among them) just don't like trailing whites. * Some other things I can't think about atm. -- Tom. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
yeah i was not blaming editors but i was pointing out the funny commit
message.
i don't think editor did type that message automatically.
anyhow still it looks so ... :)
Daniel Juyung Seo (SeoZ)
On Oct 23, 2011 4:56 PM, "Carsten Haitzler" wrote:
> On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo >
> said:
>
> i see my test worked. the irrational formatting pedants now come out of the
> woodwork. i did this to see just who would respond and how.
>
> i added spaces on BLANK LINES that align with indenting. all it takes is an
> enter or hitting tab. all editors do this by default (with autoindent on).
>
> are these pedants (like you and vincent) proposing that we fight against
> our
> editors and keep undoing the work they do for us? i assume the answer is
> yes
> because this whole thing is irrational.
>
> > Well... This is my personal opinion about this commit.
> > This is so disappointing and childish as a grown-up person.
> >
> > I didn't set that vim configuration before I was requested to remove
> > trailing whitespaces from enlightenment community.
> > Now e-founder encourages trailing whitespaces.
> > Seriously that's so funny.
> >
> > Anyhow, I have no objection to you doing this funny behavior because
> > it looks like trailing whitespace is now allowed in enlightenment.
> >
> > Thanks.
> >
> > Daniel Juyung Seo (SeoZ)
> >
> > On Sun, Oct 23, 2011 at 12:51 PM, Enlightenment SVN
> > wrote:
> > > Log:
> > > annoy vim users with spaces at the start of blank lines. :)
> > >
> > >
> > >
> > > Author: raster
> > > Date: 2011-10-22 20:51:41 -0700 (Sat, 22 Oct 2011)
> > > New Revision: 64317
> > > Trac: http://trac.enlightenment.org/e/changeset/64317
> > >
> > > Modified:
> > > trunk/evas/src/lib/canvas/evas_async_events.c
> > >
> > > Modified: trunk/evas/src/lib/canvas/evas_async_events.c
> > > ===
> > > --- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-22
> 23:40:48
> > > UTC (rev 64316) +++ trunk/evas/src/lib/canvas/evas_async_events.c
> > > 2011-10-23 03:51:41 UTC (rev 64317) @@ -3,11 +3,11 @@
> > >
> > > #ifdef BUILD_ASYNC_EVENTS
> > >
> > > -#ifndef _MSC_VER
> > > -# include
> > > -#endif
> > > -#include
> > > -#include
> > > +# ifndef _MSC_VER
> > > +# include
> > > +# endif
> > > +# include
> > > +# include
> > >
> > > static int _fd_write = -1;
> > > static int _fd_read = -1;
> > > @@ -28,21 +28,21 @@
> > > evas_async_events_init(void)
> > > {
> > >int filedes[2];
> > > -
> > > +
> > >_init_evas_event++;
> > >if (_init_evas_event > 1) return _init_evas_event;
> > > -
> > > +
> > >if (pipe(filedes) == -1)
> > > {
> > >_init_evas_event = 0;
> > >return 0;
> > > }
> > > -
> > > +
> > >_fd_read = filedes[0];
> > >_fd_write = filedes[1];
> > > -
> > > +
> > >fcntl(_fd_read, F_SETFL, O_NONBLOCK);
> > > -
> > > +
> > >return _init_evas_event;
> > > }
> > >
> > > @@ -51,12 +51,12 @@
> > > {
> > >_init_evas_event--;
> > >if (_init_evas_event > 0) return _init_evas_event;
> > > -
> > > +
> > >close(_fd_read);
> > >close(_fd_write);
> > >_fd_read = -1;
> > >_fd_write = -1;
> > > -
> > > +
> > >return _init_evas_event;
> > > }
> > >
> > > @@ -79,10 +79,10 @@
> > >Evas_Event_Async *ev;
> > >int check;
> > >int count = 0;
> > > -
> > > +
> > >if (_fd_read == -1) return 0;
> > > -
> > > - do
> > > +
> > > + do
> > > {
> > >check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
> > >
> > > @@ -92,11 +92,11 @@
> > > free(ev);
> > > count++;
> > > }
> > > - }
> > > + }
> > >while (check > 0);
> > > -
> > > +
> > >evas_cache_image_wakeup();
> > > -
> > > +
> > >if (check < 0)
> > > {
> > > switch (errno)
> > > @@ -108,7 +108,7 @@
> > > _fd_read = -1;
> > > }
> > > }
> > > -
> > > +
> > >return count;
> > > #else
> > >return 0;
> > > @@ -122,27 +122,27 @@
> > >Evas_Event_Async *ev;
> > >ssize_t check;
> > >Eina_Bool result = EINA_FALSE;
> > > -
> > > +
> > >if (!func) return 0;
> > >if (_fd_write == -1) return 0;
> > > -
> > > +
> > >ev = calloc(1, sizeof (Evas_Event_Async));
> > >if (!ev) return 0;
> > > -
> > > +
> > >ev->func = func;
> > >ev->target = target;
> > >ev->type = type;
> > >ev->event_info = event_info;
> > > -
> > > - do
> > > +
> > > + do
> > > {
> > > check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> > > }
> > > - while ((check != sizeof (Evas_Event_Async*)) &&
> > > + while ((check != sizeof (Evas_Event_Async*)) &&
> > > ((errno == EINTR) || (errno == EAGAIN)));
> > > -
> > > +
> > >evas_cache_image_wakeup();
> > > -
> > > +
> > >if (check == sizeof (Evas_Event_Async*))
> > > result = EINA_TRUE;
> > >else
> > > @@ -156,7 +156,7 @@
> > > _
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 23 Oct 2011, Carsten Haitzler (The Rasterman) wrote:
On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo
said:
i see my test worked. the irrational formatting pedants now come out of the
woodwork. i did this to see just who would respond and how.
i added spaces on BLANK LINES that align with indenting. all it takes is an
enter or hitting tab. all editors do this by default (with autoindent on).
are these pedants (like you and vincent) proposing that we fight against our
editors and keep undoing the work they do for us? i assume the answer is yes
because this whole thing is irrational.
no : the parsing fo the files is faster without these white spaces, so
it's not illogical :p
Vincent
Well... This is my personal opinion about this commit.
This is so disappointing and childish as a grown-up person.
I didn't set that vim configuration before I was requested to remove
trailing whitespaces from enlightenment community.
Now e-founder encourages trailing whitespaces.
Seriously that's so funny.
Anyhow, I have no objection to you doing this funny behavior because
it looks like trailing whitespace is now allowed in enlightenment.
Thanks.
Daniel Juyung Seo (SeoZ)
On Sun, Oct 23, 2011 at 12:51 PM, Enlightenment SVN
wrote:
Log:
annoy vim users with spaces at the start of blank lines. :)
Author: raster
Date: 2011-10-22 20:51:41 -0700 (Sat, 22 Oct 2011)
New Revision: 64317
Trac: http://trac.enlightenment.org/e/changeset/64317
Modified:
trunk/evas/src/lib/canvas/evas_async_events.c
Modified: trunk/evas/src/lib/canvas/evas_async_events.c
===
--- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-22 23:40:48
UTC (rev 64316) +++ trunk/evas/src/lib/canvas/evas_async_events.c
2011-10-23 03:51:41 UTC (rev 64317) @@ -3,11 +3,11 @@
#ifdef BUILD_ASYNC_EVENTS
-#ifndef _MSC_VER
-# include
-#endif
-#include
-#include
+# ifndef _MSC_VER
+# include
+# endif
+# include
+# include
static int _fd_write = -1;
static int _fd_read = -1;
@@ -28,21 +28,21 @@
evas_async_events_init(void)
{
int filedes[2];
-
+
_init_evas_event++;
if (_init_evas_event > 1) return _init_evas_event;
-
+
if (pipe(filedes) == -1)
{
_init_evas_event = 0;
return 0;
}
-
+
_fd_read = filedes[0];
_fd_write = filedes[1];
-
+
fcntl(_fd_read, F_SETFL, O_NONBLOCK);
-
+
return _init_evas_event;
}
@@ -51,12 +51,12 @@
{
_init_evas_event--;
if (_init_evas_event > 0) return _init_evas_event;
-
+
close(_fd_read);
close(_fd_write);
_fd_read = -1;
_fd_write = -1;
-
+
return _init_evas_event;
}
@@ -79,10 +79,10 @@
Evas_Event_Async *ev;
int check;
int count = 0;
-
+
if (_fd_read == -1) return 0;
-
- do
+
+ do
{
check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
@@ -92,11 +92,11 @@
free(ev);
count++;
}
- }
+ }
while (check > 0);
-
+
evas_cache_image_wakeup();
-
+
if (check < 0)
{
switch (errno)
@@ -108,7 +108,7 @@
_fd_read = -1;
}
}
-
+
return count;
#else
return 0;
@@ -122,27 +122,27 @@
Evas_Event_Async *ev;
ssize_t check;
Eina_Bool result = EINA_FALSE;
-
+
if (!func) return 0;
if (_fd_write == -1) return 0;
-
+
ev = calloc(1, sizeof (Evas_Event_Async));
if (!ev) return 0;
-
+
ev->func = func;
ev->target = target;
ev->type = type;
ev->event_info = event_info;
-
- do
+
+ do
{
check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
}
- while ((check != sizeof (Evas_Event_Async*)) &&
+ while ((check != sizeof (Evas_Event_Async*)) &&
((errno == EINTR) || (errno == EAGAIN)));
-
+
evas_cache_image_wakeup();
-
+
if (check == sizeof (Evas_Event_Async*))
result = EINA_TRUE;
else
@@ -156,7 +156,7 @@
_fd_write = -1;
}
}
-
+
return result;
#else
func(target, type, event_info);
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
__
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 23 Oct 2011 15:41:25 +0900 Daniel Juyung Seo
said:
i see my test worked. the irrational formatting pedants now come out of the
woodwork. i did this to see just who would respond and how.
i added spaces on BLANK LINES that align with indenting. all it takes is an
enter or hitting tab. all editors do this by default (with autoindent on).
are these pedants (like you and vincent) proposing that we fight against our
editors and keep undoing the work they do for us? i assume the answer is yes
because this whole thing is irrational.
> Well... This is my personal opinion about this commit.
> This is so disappointing and childish as a grown-up person.
>
> I didn't set that vim configuration before I was requested to remove
> trailing whitespaces from enlightenment community.
> Now e-founder encourages trailing whitespaces.
> Seriously that's so funny.
>
> Anyhow, I have no objection to you doing this funny behavior because
> it looks like trailing whitespace is now allowed in enlightenment.
>
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
> On Sun, Oct 23, 2011 at 12:51 PM, Enlightenment SVN
> wrote:
> > Log:
> > annoy vim users with spaces at the start of blank lines. :)
> >
> >
> >
> > Author: raster
> > Date: 2011-10-22 20:51:41 -0700 (Sat, 22 Oct 2011)
> > New Revision: 64317
> > Trac: http://trac.enlightenment.org/e/changeset/64317
> >
> > Modified:
> > trunk/evas/src/lib/canvas/evas_async_events.c
> >
> > Modified: trunk/evas/src/lib/canvas/evas_async_events.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-22 23:40:48
> > UTC (rev 64316) +++ trunk/evas/src/lib/canvas/evas_async_events.c
> > 2011-10-23 03:51:41 UTC (rev 64317) @@ -3,11 +3,11 @@
> >
> > #ifdef BUILD_ASYNC_EVENTS
> >
> > -#ifndef _MSC_VER
> > -# include
> > -#endif
> > -#include
> > -#include
> > +# ifndef _MSC_VER
> > +# include
> > +# endif
> > +# include
> > +# include
> >
> > static int _fd_write = -1;
> > static int _fd_read = -1;
> > @@ -28,21 +28,21 @@
> > evas_async_events_init(void)
> > {
> > int filedes[2];
> > -
> > +
> > _init_evas_event++;
> > if (_init_evas_event > 1) return _init_evas_event;
> > -
> > +
> > if (pipe(filedes) == -1)
> > {
> > _init_evas_event = 0;
> > return 0;
> > }
> > -
> > +
> > _fd_read = filedes[0];
> > _fd_write = filedes[1];
> > -
> > +
> > fcntl(_fd_read, F_SETFL, O_NONBLOCK);
> > -
> > +
> > return _init_evas_event;
> > }
> >
> > @@ -51,12 +51,12 @@
> > {
> > _init_evas_event--;
> > if (_init_evas_event > 0) return _init_evas_event;
> > -
> > +
> > close(_fd_read);
> > close(_fd_write);
> > _fd_read = -1;
> > _fd_write = -1;
> > -
> > +
> > return _init_evas_event;
> > }
> >
> > @@ -79,10 +79,10 @@
> > Evas_Event_Async *ev;
> > int check;
> > int count = 0;
> > -
> > +
> > if (_fd_read == -1) return 0;
> > -
> > - do
> > +
> > + do
> > {
> > check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
> >
> > @@ -92,11 +92,11 @@
> > free(ev);
> > count++;
> > }
> > - }
> > + }
> > while (check > 0);
> > -
> > +
> > evas_cache_image_wakeup();
> > -
> > +
> > if (check < 0)
> > {
> > switch (errno)
> > @@ -108,7 +108,7 @@
> > _fd_read = -1;
> > }
> > }
> > -
> > +
> > return count;
> > #else
> > return 0;
> > @@ -122,27 +122,27 @@
> > Evas_Event_Async *ev;
> > ssize_t check;
> > Eina_Bool result = EINA_FALSE;
> > -
> > +
> > if (!func) return 0;
> > if (_fd_write == -1) return 0;
> > -
> > +
> > ev = calloc(1, sizeof (Evas_Event_Async));
> > if (!ev) return 0;
> > -
> > +
> > ev->func = func;
> > ev->target = target;
> > ev->type = type;
> > ev->event_info = event_info;
> > -
> > - do
> > +
> > + do
> > {
> > check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> > }
> > - while ((check != sizeof (Evas_Event_Async*)) &&
> > + while ((check != sizeof (Evas_Event_Async*)) &&
> > ((errno == EINTR) || (errno == EAGAIN)));
> > -
> > +
> > evas_cache_image_wakeup();
> > -
> > +
> > if (check == sizeof (Evas_Event_Async*))
> > result = EINA_TRUE;
> > else
> > @@ -156,7 +156,7 @@
> > _fd_write = -1;
> > }
> > }
> > -
> > +
> > return result;
> > #else
> > func(target, type, event_info);
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-svn
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sun, 23 Oct 2011, Daniel Juyung Seo wrote:
Well... This is my personal opinion about this commit.
This is so disappointing and childish as a grown-up person.
I didn't set that vim configuration before I was requested to remove
trailing whitespaces from enlightenment community.
Now e-founder encourages trailing whitespaces.
Seriously that's so funny.
Anyhow, I have no objection to you doing this funny behavior because
it looks like trailing whitespace is now allowed in enlightenment.
hell no, i'm against those trailing whitespaces too, the only one who
does not care is raster. Most all other devs remove them.
Vincent
Thanks.
Daniel Juyung Seo (SeoZ)
On Sun, Oct 23, 2011 at 12:51 PM, Enlightenment SVN
wrote:
Log:
annoy vim users with spaces at the start of blank lines. :)
Author: raster
Date: 2011-10-22 20:51:41 -0700 (Sat, 22 Oct 2011)
New Revision: 64317
Trac: http://trac.enlightenment.org/e/changeset/64317
Modified:
trunk/evas/src/lib/canvas/evas_async_events.c
Modified: trunk/evas/src/lib/canvas/evas_async_events.c
===
--- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-22 23:40:48 UTC
(rev 64316)
+++ trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-23 03:51:41 UTC
(rev 64317)
@@ -3,11 +3,11 @@
#ifdef BUILD_ASYNC_EVENTS
-#ifndef _MSC_VER
-# include
-#endif
-#include
-#include
+# ifndef _MSC_VER
+# include
+# endif
+# include
+# include
static int _fd_write = -1;
static int _fd_read = -1;
@@ -28,21 +28,21 @@
evas_async_events_init(void)
{
int filedes[2];
-
+
_init_evas_event++;
if (_init_evas_event > 1) return _init_evas_event;
-
+
if (pipe(filedes) == -1)
{
_init_evas_event = 0;
return 0;
}
-
+
_fd_read = filedes[0];
_fd_write = filedes[1];
-
+
fcntl(_fd_read, F_SETFL, O_NONBLOCK);
-
+
return _init_evas_event;
}
@@ -51,12 +51,12 @@
{
_init_evas_event--;
if (_init_evas_event > 0) return _init_evas_event;
-
+
close(_fd_read);
close(_fd_write);
_fd_read = -1;
_fd_write = -1;
-
+
return _init_evas_event;
}
@@ -79,10 +79,10 @@
Evas_Event_Async *ev;
int check;
int count = 0;
-
+
if (_fd_read == -1) return 0;
-
- do
+
+ do
{
check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
@@ -92,11 +92,11 @@
free(ev);
count++;
}
- }
+ }
while (check > 0);
-
+
evas_cache_image_wakeup();
-
+
if (check < 0)
{
switch (errno)
@@ -108,7 +108,7 @@
_fd_read = -1;
}
}
-
+
return count;
#else
return 0;
@@ -122,27 +122,27 @@
Evas_Event_Async *ev;
ssize_t check;
Eina_Bool result = EINA_FALSE;
-
+
if (!func) return 0;
if (_fd_write == -1) return 0;
-
+
ev = calloc(1, sizeof (Evas_Event_Async));
if (!ev) return 0;
-
+
ev->func = func;
ev->target = target;
ev->type = type;
ev->event_info = event_info;
-
- do
+
+ do
{
check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
}
- while ((check != sizeof (Evas_Event_Async*)) &&
+ while ((check != sizeof (Evas_Event_Async*)) &&
((errno == EINTR) || (errno == EAGAIN)));
-
+
evas_cache_image_wakeup();
-
+
if (check == sizeof (Evas_Event_Async*))
result = EINA_TRUE;
else
@@ -156,7 +156,7 @@
_fd_write = -1;
}
}
-
+
return result;
#else
func(target, type, event_info);
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
htt
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
Well... This is my personal opinion about this commit.
This is so disappointing and childish as a grown-up person.
I didn't set that vim configuration before I was requested to remove
trailing whitespaces from enlightenment community.
Now e-founder encourages trailing whitespaces.
Seriously that's so funny.
Anyhow, I have no objection to you doing this funny behavior because
it looks like trailing whitespace is now allowed in enlightenment.
Thanks.
Daniel Juyung Seo (SeoZ)
On Sun, Oct 23, 2011 at 12:51 PM, Enlightenment SVN
wrote:
> Log:
> annoy vim users with spaces at the start of blank lines. :)
>
>
>
> Author: raster
> Date: 2011-10-22 20:51:41 -0700 (Sat, 22 Oct 2011)
> New Revision: 64317
> Trac: http://trac.enlightenment.org/e/changeset/64317
>
> Modified:
> trunk/evas/src/lib/canvas/evas_async_events.c
>
> Modified: trunk/evas/src/lib/canvas/evas_async_events.c
> ===
> --- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-22 23:40:48
> UTC (rev 64316)
> +++ trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-23 03:51:41
> UTC (rev 64317)
> @@ -3,11 +3,11 @@
>
> #ifdef BUILD_ASYNC_EVENTS
>
> -#ifndef _MSC_VER
> -# include
> -#endif
> -#include
> -#include
> +# ifndef _MSC_VER
> +# include
> +# endif
> +# include
> +# include
>
> static int _fd_write = -1;
> static int _fd_read = -1;
> @@ -28,21 +28,21 @@
> evas_async_events_init(void)
> {
> int filedes[2];
> -
> +
> _init_evas_event++;
> if (_init_evas_event > 1) return _init_evas_event;
> -
> +
> if (pipe(filedes) == -1)
> {
> _init_evas_event = 0;
> return 0;
> }
> -
> +
> _fd_read = filedes[0];
> _fd_write = filedes[1];
> -
> +
> fcntl(_fd_read, F_SETFL, O_NONBLOCK);
> -
> +
> return _init_evas_event;
> }
>
> @@ -51,12 +51,12 @@
> {
> _init_evas_event--;
> if (_init_evas_event > 0) return _init_evas_event;
> -
> +
> close(_fd_read);
> close(_fd_write);
> _fd_read = -1;
> _fd_write = -1;
> -
> +
> return _init_evas_event;
> }
>
> @@ -79,10 +79,10 @@
> Evas_Event_Async *ev;
> int check;
> int count = 0;
> -
> +
> if (_fd_read == -1) return 0;
> -
> - do
> +
> + do
> {
> check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
>
> @@ -92,11 +92,11 @@
> free(ev);
> count++;
> }
> - }
> + }
> while (check > 0);
> -
> +
> evas_cache_image_wakeup();
> -
> +
> if (check < 0)
> {
> switch (errno)
> @@ -108,7 +108,7 @@
> _fd_read = -1;
> }
> }
> -
> +
> return count;
> #else
> return 0;
> @@ -122,27 +122,27 @@
> Evas_Event_Async *ev;
> ssize_t check;
> Eina_Bool result = EINA_FALSE;
> -
> +
> if (!func) return 0;
> if (_fd_write == -1) return 0;
> -
> +
> ev = calloc(1, sizeof (Evas_Event_Async));
> if (!ev) return 0;
> -
> +
> ev->func = func;
> ev->target = target;
> ev->type = type;
> ev->event_info = event_info;
> -
> - do
> +
> + do
> {
> check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> }
> - while ((check != sizeof (Evas_Event_Async*)) &&
> + while ((check != sizeof (Evas_Event_Async*)) &&
> ((errno == EINTR) || (errno == EAGAIN)));
> -
> +
> evas_cache_image_wakeup();
> -
> +
> if (check == sizeof (Evas_Event_Async*))
> result = EINA_TRUE;
> else
> @@ -156,7 +156,7 @@
> _fd_write = -1;
> }
> }
> -
> +
> return result;
> #else
> func(target, type, event_info);
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Sat, 22 Oct 2011 00:47:33 +0900 Daniel Juyung Seo
said:
> Spank spank raster!
> This introduces trailing whitespaces.
turn off your annoyance mode in your editor. fyi if u mean trailing white
spaces at the START of blank lines - thats actually HOW many editors work on
autoindent... because they are EXPECTING you to write some code there. it's
perfectly logical and all you are doing is bitching about something that is
actually a good thing because you insist on having an hyper-annoying editor
feature on.
> Daniel Juyung Seo (SeoZ)
>
> On Fri, Oct 21, 2011 at 2:50 PM, Enlightenment SVN
> wrote:
> > Log:
> > nicer formatting of async events
> >
> >
> >
> > Author: raster
> > Date: 2011-10-20 22:50:05 -0700 (Thu, 20 Oct 2011)
> > New Revision: 64240
> > Trac: http://trac.enlightenment.org/e/changeset/64240
> >
> > Modified:
> > trunk/evas/src/lib/canvas/evas_async_events.c
> >
> > Modified: trunk/evas/src/lib/canvas/evas_async_events.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-21 05:40:59
> > UTC (rev 64239) +++ trunk/evas/src/lib/canvas/evas_async_events.c
> > 2011-10-21 05:50:05 UTC (rev 64240) @@ -82,28 +82,32 @@
> >
> > if (_fd_read == -1) return 0;
> >
> > - do {
> > + do
> > + {
> > check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
> > -
> > +
> > if (check == sizeof (Evas_Event_Async *))
> > {
> > if (ev->func) ev->func((void *)ev->target, ev->type,
> > ev->event_info); free(ev);
> > count++;
> > }
> > - } while (check > 0);
> > + }
> > + while (check > 0);
> >
> > evas_cache_image_wakeup();
> >
> > if (check < 0)
> > - switch (errno)
> > - {
> > - case EBADF:
> > - case EINVAL:
> > - case EIO:
> > - case EISDIR:
> > - _fd_read = -1;
> > - }
> > + {
> > + switch (errno)
> > + {
> > + case EBADF:
> > + case EINVAL:
> > + case EIO:
> > + case EISDIR:
> > + _fd_read = -1;
> > + }
> > + }
> >
> > return count;
> > #else
> > @@ -130,23 +134,28 @@
> > ev->type = type;
> > ev->event_info = event_info;
> >
> > - do {
> > - check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> > - } while ((check != sizeof (Evas_Event_Async*)) && ((errno == EINTR) ||
> > (errno == EAGAIN)));
> > + do
> > + {
> > + check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> > + }
> > + while ((check != sizeof (Evas_Event_Async*)) &&
> > + ((errno == EINTR) || (errno == EAGAIN)));
> >
> > evas_cache_image_wakeup();
> >
> > if (check == sizeof (Evas_Event_Async*))
> > result = EINA_TRUE;
> > else
> > - switch (errno)
> > - {
> > - case EBADF:
> > - case EINVAL:
> > - case EIO:
> > - case EPIPE:
> > - _fd_write = -1;
> > - }
> > + {
> > + switch (errno)
> > + {
> > + case EBADF:
> > + case EINVAL:
> > + case EIO:
> > + case EPIPE:
> > + _fd_write = -1;
> > + }
> > + }
> >
> > return result;
> > #else
> >
> >
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > enlightenment-svn mailing list
> > enlightenment-...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
> >
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
Spank spank raster!
This introduces trailing whitespaces.
Daniel Juyung Seo (SeoZ)
On Fri, Oct 21, 2011 at 2:50 PM, Enlightenment SVN
wrote:
> Log:
> nicer formatting of async events
>
>
>
> Author: raster
> Date: 2011-10-20 22:50:05 -0700 (Thu, 20 Oct 2011)
> New Revision: 64240
> Trac: http://trac.enlightenment.org/e/changeset/64240
>
> Modified:
> trunk/evas/src/lib/canvas/evas_async_events.c
>
> Modified: trunk/evas/src/lib/canvas/evas_async_events.c
> ===
> --- trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-21 05:40:59
> UTC (rev 64239)
> +++ trunk/evas/src/lib/canvas/evas_async_events.c 2011-10-21 05:50:05
> UTC (rev 64240)
> @@ -82,28 +82,32 @@
>
> if (_fd_read == -1) return 0;
>
> - do {
> + do
> + {
> check = read(_fd_read, &ev, sizeof (Evas_Event_Async *));
> -
> +
> if (check == sizeof (Evas_Event_Async *))
> {
> if (ev->func) ev->func((void *)ev->target, ev->type,
> ev->event_info);
> free(ev);
> count++;
> }
> - } while (check > 0);
> + }
> + while (check > 0);
>
> evas_cache_image_wakeup();
>
> if (check < 0)
> - switch (errno)
> - {
> - case EBADF:
> - case EINVAL:
> - case EIO:
> - case EISDIR:
> - _fd_read = -1;
> - }
> + {
> + switch (errno)
> + {
> + case EBADF:
> + case EINVAL:
> + case EIO:
> + case EISDIR:
> + _fd_read = -1;
> + }
> + }
>
> return count;
> #else
> @@ -130,23 +134,28 @@
> ev->type = type;
> ev->event_info = event_info;
>
> - do {
> - check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> - } while ((check != sizeof (Evas_Event_Async*)) && ((errno == EINTR) ||
> (errno == EAGAIN)));
> + do
> + {
> + check = write(_fd_write, &ev, sizeof (Evas_Event_Async*));
> + }
> + while ((check != sizeof (Evas_Event_Async*)) &&
> + ((errno == EINTR) || (errno == EAGAIN)));
>
> evas_cache_image_wakeup();
>
> if (check == sizeof (Evas_Event_Async*))
> result = EINA_TRUE;
> else
> - switch (errno)
> - {
> - case EBADF:
> - case EINVAL:
> - case EIO:
> - case EPIPE:
> - _fd_write = -1;
> - }
> + {
> + switch (errno)
> + {
> + case EBADF:
> + case EINVAL:
> + case EIO:
> + case EPIPE:
> + _fd_write = -1;
> + }
> + }
>
> return result;
> #else
>
>
> --
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Fri, 21 Oct 2011 12:34:05 +0200 Cedric BAIL said: > On Fri, Oct 21, 2011 at 12:00 PM, Enlightenment SVN > wrote: > > Log: > > and disable invalidate optimization > > > > > > > > Author: raster > > Date: 2011-10-21 03:00:03 -0700 (Fri, 21 Oct 2011) > > New Revision: 64249 > > Trac: http://trac.enlightenment.org/e/changeset/64249 > > > > Modified: > > trunk/evas/src/lib/canvas/evas_render.c > > > > Modified: trunk/evas/src/lib/canvas/evas_render.c > > === > > --- trunk/evas/src/lib/canvas/evas_render.c 2011-10-21 09:59:13 UTC > > (rev 64248) +++ trunk/evas/src/lib/canvas/evas_render.c 2011-10-21 > > 10:00:03 UTC (rev 64249) @@ -1295,7 +1295,7 @@ > > _evas_render_check_pending_objects(&e->pending_objects, e); > > > > /* phase 1. add extra updates for changed objects */ > > - if (e->invalidate || e->render_objects.count <= 0) > > +/* if (e->invalidate || e->render_objects.count <= 0)*/ > > clean_them = _evas_render_phase1_process(e, > > &e->active_objects, > > &e->restack_objects, > > This optimisation does really impact performance on low end hardware > when they are not using evas map. Could you tell me what was the issue > ? How to reproduce it ? So I can bring this optimisation back in problem is actually this: object a changes. object b is a big solid object covering obj a entirely. b does NOT change. now we render. we SHOULD reduce this to a nop. but we dont. we are rendering the change region even though its obscured. it's a bug. i reverted this already as i thought this was the quick fix. it did - but it created new bugs. i fixed it elsewhere, but now there is yet another corner case it doesnt detect and i don't know why. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Fri, Oct 21, 2011 at 12:00 PM, Enlightenment SVN wrote: > Log: > and disable invalidate optimization > > > > Author: raster > Date: 2011-10-21 03:00:03 -0700 (Fri, 21 Oct 2011) > New Revision: 64249 > Trac: http://trac.enlightenment.org/e/changeset/64249 > > Modified: > trunk/evas/src/lib/canvas/evas_render.c > > Modified: trunk/evas/src/lib/canvas/evas_render.c > === > --- trunk/evas/src/lib/canvas/evas_render.c 2011-10-21 09:59:13 UTC (rev > 64248) > +++ trunk/evas/src/lib/canvas/evas_render.c 2011-10-21 10:00:03 UTC (rev > 64249) > @@ -1295,7 +1295,7 @@ > _evas_render_check_pending_objects(&e->pending_objects, e); > > /* phase 1. add extra updates for changed objects */ > - if (e->invalidate || e->render_objects.count <= 0) > +/* if (e->invalidate || e->render_objects.count <= 0)*/ > clean_them = _evas_render_phase1_process(e, > &e->active_objects, > &e->restack_objects, This optimisation does really impact performance on low end hardware when they are not using evas map. Could you tell me what was the issue ? How to reproduce it ? So I can bring this optimisation back in. Thanks -- Cedric BAIL -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
2011/10/11 Vincent Torri : > > > On Tue, 11 Oct 2011, Vincent Torri wrote: > >>> >>> correct. in some cases where 15.9 cannot in fp be represented as >>> a value >= 16.0, this it gets slightly rounded down, and thus ends up being >>> 15 >>> when dropped down to an integer. that is the whole crux of the problem. >> >> the almost all the code using ceil() and floor() is broken, as the result >> of these functions is almost always casted to an int... >> >>> so that means non-c99 platforms will have rendering bugs. there has to be a >>> better way. >> >> I don't know any. If someone has a clue... > > http://cgit.freedesktop.org/cairo/tree/src/cairo-misc.c#n487 :O voodoo math > > Vincent > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Tue, 11 Oct 2011, Vincent Torri wrote: >> >> correct. in some cases where 15.9 cannot in fp be represented as >> a value >= 16.0, this it gets slightly rounded down, and thus ends up being >> 15 >> when dropped down to an integer. that is the whole crux of the problem. > > the almost all the code using ceil() and floor() is broken, as the result > of these functions is almost always casted to an int... > >> so that means non-c99 platforms will have rendering bugs. there has to be a >> better way. > > I don't know any. If someone has a clue... http://cgit.freedesktop.org/cairo/tree/src/cairo-misc.c#n487 Vincent -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote: > On Tue, 11 Oct 2011 08:40:33 +0200 (CEST) Vincent Torri > said: > >> >> >> On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote: >> >>> On Tue, 11 Oct 2011 08:14:47 +0200 (CEST) Vincent Torri >>> said: >>> On Mon, 10 Oct 2011, Enlightenment SVN wrote: > Log: > use lround() for map coord rounding to avoid silly things like > 15.98 rounding down to 15... whihc leads to > sometimes... odd off-by-1 expected results. lround is C99 compliant and does not exist on Windows. why not using the macro #define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5)) >>> >>> because 1. i dont have a manual page for what is NOT supported in windows's >>> dev envs (that's why we have you!). >> >> in google : "msdn the_function" >> >> Also, did you read the man page of lround ? > > i did. > > ... > long long int llroundl(long double x); > > Link with -lm. > > Feature Test Macro Requirements for glibc (see feature_test_macros(7)): > > All functions shown above: > _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE || > _POSIX_C_SOURCE >= 200112L; > or cc -std=c99 > ... > CONFORMING TO > C99, POSIX.1-2001. > ... > > nothing in the manual page on ubuntu requires any special compile flags other > than -lm (as per usual) for linking. the manual differs from the one you quote > below. that manual is better than most of the manual I read. I also use the opengroup one too. > note that the manula i have seems more complete. as such the standard > for efl is c99 as an assumed base. I thought it was POSIX... > >> See >> >> http://linux.die.net/man/3/lround >> >> did you read the line "Compile with -std=c99" ? Is that flag passed to the >> compiler ? Note that i added an m4 macro that checks if a flags is >> supported by the compiler >> >> 2. floor and ceil return doubles, not >>> integers. lround returns a long int (long). >> >> so (long)ceil(15.999) does not return 16 ? > > correct. in some cases where 15.9 cannot in fp be represented as > a value >= 16.0, this it gets slightly rounded down, and thus ends up being 15 > when dropped down to an integer. that is the whole crux of the problem. the almost all the code using ceil() and floor() is broken, as the result of these functions is almost always casted to an int... > so that means non-c99 platforms will have rendering bugs. there has to be a > better way. I don't know any. If someone has a clue... Vincent > >> then >> >> #ifndef HAVE_LROUND >> # define lround >> #endif >> >> Vincent >> >> -- >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Tue, 11 Oct 2011, Lucas De Marchi wrote: Hi Vincent, On Tue, Oct 11, 2011 at 3:40 AM, Vincent Torri wrote: On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote: On Tue, 11 Oct 2011 08:14:47 +0200 (CEST) Vincent Torri said: On Mon, 10 Oct 2011, Enlightenment SVN wrote: Log: use lround() for map coord rounding to avoid silly things like 15.98 rounding down to 15... whihc leads to sometimes... odd off-by-1 expected results. lround is C99 compliant and does not exist on Windows. why not using the macro #define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5)) because 1. i dont have a manual page for what is NOT supported in windows's dev envs (that's why we have you!). in google : "msdn the_function" Also, did you read the man page of lround ? See http://linux.die.net/man/3/lround did you read the line "Compile with -std=c99" ? Is that flag passed to the compiler ? Note that i added an m4 macro that checks if a flags is supported by the compiler sigh... there's no support for C99 in windows? Hey, it's a 12 years old standard. Isn't evil supposed to cover these differences without staying in our way? I'm not saying it should already have "lround", but now it should be added, right? even if it's a 12 years old standard, most of compilers don't even implement it completely : http://gcc.gnu.org/c99status.html And it has already been said that vc++ aim is not to be C99 compliant. It's not one of the purpose of the vc++ developpers. Vincent-- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Tue, 11 Oct 2011 08:40:33 +0200 (CEST) Vincent Torri said: > > > On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 11 Oct 2011 08:14:47 +0200 (CEST) Vincent Torri > > said: > > > >> > >> > >> On Mon, 10 Oct 2011, Enlightenment SVN wrote: > >> > >>> Log: > >>> use lround() for map coord rounding to avoid silly things like > >>> 15.98 rounding down to 15... whihc leads to > >>> sometimes... odd off-by-1 expected results. > >> > >> lround is C99 compliant and does not exist on Windows. > >> > >> why not using the macro > >> > >> #define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5)) > > > > because 1. i dont have a manual page for what is NOT supported in windows's > > dev envs (that's why we have you!). > > in google : "msdn the_function" > > Also, did you read the man page of lround ? i did. ... long long int llroundl(long double x); Link with -lm. Feature Test Macro Requirements for glibc (see feature_test_macros(7)): All functions shown above: _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L; or cc -std=c99 ... CONFORMING TO C99, POSIX.1-2001. ... nothing in the manual page on ubuntu requires any special compile flags other than -lm (as per usual) for linking. the manual differs from the one you quote below. note that the manula i have seems more complete. as such the standard for efl is c99 as an assumed base. > See > > http://linux.die.net/man/3/lround > > did you read the line "Compile with -std=c99" ? Is that flag passed to the > compiler ? Note that i added an m4 macro that checks if a flags is > supported by the compiler > > 2. floor and ceil return doubles, not > > integers. lround returns a long int (long). > > so (long)ceil(15.999) does not return 16 ? correct. in some cases where 15.9 cannot in fp be represented as a value >= 16.0, this it gets slightly rounded down, and thus ends up being 15 when dropped down to an integer. that is the whole crux of the problem. > > why not do it that way? less efficient than a single lround call. and > > technically incorrect. i'm literally trying to solve minuscule rounding > > issues here and returning a rounded double could still return an inaccurate > > (by a very tiny margin) double that will still get rounded the wrong way. : > > ( need a call that rounds and returns an integer type (int, long, etc.) not > > a double or float. > > The, at least, check the availability in configure.ac so that means non-c99 platforms will have rendering bugs. there has to be a better way. > then > > #ifndef HAVE_LROUND > # define lround > #endif > > Vincent > > -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
Hi Vincent, On Tue, Oct 11, 2011 at 3:40 AM, Vincent Torri wrote: > > > On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 11 Oct 2011 08:14:47 +0200 (CEST) Vincent Torri > > > > said: > > > >> > >> > >> On Mon, 10 Oct 2011, Enlightenment SVN wrote: > >> > >>> Log: > >>> use lround() for map coord rounding to avoid silly things like > >>> 15.98 rounding down to 15... whihc leads to > >>> sometimes... odd off-by-1 expected results. > >> > >> lround is C99 compliant and does not exist on Windows. > >> > >> why not using the macro > >> > >> #define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5)) > > > > because 1. i dont have a manual page for what is NOT supported in windows's > > dev > > envs (that's why we have you!). > > in google : "msdn the_function" > > Also, did you read the man page of lround ? > > See > > http://linux.die.net/man/3/lround > > did you read the line "Compile with -std=c99" ? Is that flag passed to the > compiler ? Note that i added an m4 macro that checks if a flags is > supported by the compiler sigh... there's no support for C99 in windows? Hey, it's a 12 years old standard. Isn't evil supposed to cover these differences without staying in our way? I'm not saying it should already have "lround", but now it should be added, right? Lucas De Marchi -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote: > On Tue, 11 Oct 2011 08:14:47 +0200 (CEST) Vincent Torri > said: > >> >> >> On Mon, 10 Oct 2011, Enlightenment SVN wrote: >> >>> Log: >>> use lround() for map coord rounding to avoid silly things like >>> 15.98 rounding down to 15... whihc leads to >>> sometimes... odd off-by-1 expected results. >> >> lround is C99 compliant and does not exist on Windows. >> >> why not using the macro >> >> #define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5)) > > because 1. i dont have a manual page for what is NOT supported in windows's > dev > envs (that's why we have you!). in google : "msdn the_function" Also, did you read the man page of lround ? See http://linux.die.net/man/3/lround did you read the line "Compile with -std=c99" ? Is that flag passed to the compiler ? Note that i added an m4 macro that checks if a flags is supported by the compiler 2. floor and ceil return doubles, not > integers. lround returns a long int (long). so (long)ceil(15.999) does not return 16 ? > why not do it that way? less efficient than a single lround call. and > technically incorrect. i'm literally trying to solve minuscule rounding issues > here and returning a rounded double could still return an inaccurate (by a > very > tiny margin) double that will still get rounded the wrong way. :( need a call > that rounds and returns an integer type (int, long, etc.) not a double or > float. The, at least, check the availability in configure.ac then #ifndef HAVE_LROUND # define lround #endif Vincent -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Tue, 11 Oct 2011 08:14:47 +0200 (CEST) Vincent Torri
said:
>
>
> On Mon, 10 Oct 2011, Enlightenment SVN wrote:
>
> > Log:
> > use lround() for map coord rounding to avoid silly things like
> > 15.98 rounding down to 15... whihc leads to
> > sometimes... odd off-by-1 expected results.
>
> lround is C99 compliant and does not exist on Windows.
>
> why not using the macro
>
> #define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5))
because 1. i dont have a manual page for what is NOT supported in windows's dev
envs (that's why we have you!). 2. floor and ceil return doubles, not
integers. lround returns a long int (long).
why not do it that way? less efficient than a single lround call. and
technically incorrect. i'm literally trying to solve minuscule rounding issues
here and returning a rounded double could still return an inaccurate (by a very
tiny margin) double that will still get rounded the wrong way. :( need a call
that rounds and returns an integer type (int, long, etc.) not a double or float.
> ?
>
> Vincent
>
> >
> >
> >
> > Author: raster
> > Date: 2011-10-10 23:06:11 -0700 (Mon, 10 Oct 2011)
> > New Revision: 63978
> > Trac: http://trac.enlightenment.org/e/changeset/63978
> >
> > Modified:
> > trunk/evas/src/lib/canvas/evas_map.c
> > trunk/evas/src/lib/canvas/evas_object_image.c
> > trunk/evas/src/lib/canvas/evas_render.c
> >
> > Modified: trunk/evas/src/lib/canvas/evas_map.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_map.c2011-10-11 05:12:06 UTC
> > (rev 63977) +++ trunk/evas/src/lib/canvas/evas_map.c2011-10-11
> > 06:06:11 UTC (rev 63978) @@ -81,10 +81,10 @@
> >
> >p = obj->cur.map->points;
> >p_end = p + obj->cur.map->count;
> > - x1 = p->x;
> > - x2 = p->x;
> > - y1 = p->y;
> > - y2 = p->y;
> > + x1 = lround(p->x);
> > + x2 = lround(p->x);
> > + y1 = lround(p->y);
> > + y2 = lround(p->y);
> >p++;
> >for (; p < p_end; p++)
> > {
> >
> > Modified: trunk/evas/src/lib/canvas/evas_object_image.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_object_image.c 2011-10-11
> > 05:12:06 UTC (rev 63977) +++
> > trunk/evas/src/lib/canvas/evas_object_image.c 2011-10-11 06:06:11
> > UTC (rev 63978) @@ -2,6 +2,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "evas_common.h"
> > #include "evas_private.h"
> > @@ -2887,14 +2888,14 @@
> > // draw geom +x +y
> > for (; p < p_end; p++, pt++)
> >{
> > - pt->x = (p->x + (double)x) * FP1;
> > - pt->y = (p->y + (double)y) * FP1;
> > - pt->z = (p->z) * FP1;
> > + pt->x = (lround(p->x) + x) * FP1;
> > + pt->y = (lround(p->y) + y) * FP1;
> > + pt->z = (lround(p->z)) * FP1;
> > pt->fx = p->px;
> > pt->fy = p->py;
> > pt->fz = p->z;
> > - pt->u = ((p->u * imagew) / uvw) * FP1;
> > - pt->v = ((p->v * imageh) / uvh) * FP1;
> > + pt->u = ((lround(p->u) * imagew) / uvw) * FP1;
> > + pt->v = ((lround(p->v) * imageh) / uvh) * FP1;
> > if (pt->u < 0) pt->u = 0;
> > else if (pt->u > (imagew * FP1)) pt->u = (imagew * FP1);
> > if (pt->v < 0) pt->v = 0;
> >
> > Modified: trunk/evas/src/lib/canvas/evas_render.c
> > ===
> > --- trunk/evas/src/lib/canvas/evas_render.c 2011-10-11 05:12:06 UTC
> > (rev 63977) +++ trunk/evas/src/lib/canvas/evas_render.c 2011-10-11
> > 06:06:11 UTC (rev 63978) @@ -1,5 +1,6 @@
> > #include "evas_common.h"
> > #include "evas_private.h"
> > +#include
> >
> > // debug rendering
> > /* #define REND_DGB 1 */
> > @@ -911,14 +912,14 @@
> > pt = pts;
> > for (; p < p_end; p++, pt++)
> > {
> > - pt->x = (p->x + (double)off_x) * FP1;
> > - pt->y = (p->y + (double)off_y) * FP1;
> > - pt->z = (p->z) * FP1;
> > + pt->x = (lround(p->x) + off_x) * FP1;
> > + pt->y = (lround(p->y) + off_y) * FP1;
> > + pt->z = (lround(p->z)) * FP1;
> > pt->fx = p->px;
> > pt->fy = p->py;
> > pt->fz = p->z;
> > - pt->u = p->u * FP1;
> > - pt->v = p->v * FP1;
> > + pt->u = lround(p->u) * FP1;
> > + pt->v = lround(p->v) * FP1;
> > if (pt->u < 0) pt->u = 0;
> > else if (pt->u > (sw * FP1)) pt->u = (sw * FP1);
> > if (pt->v < 0) pt->v = 0;
> >
> >
> > --
> > All the data continuously generated i
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Mon, 10 Oct 2011, Enlightenment SVN wrote:
> Log:
> use lround() for map coord rounding to avoid silly things like
> 15.98 rounding down to 15... whihc leads to
> sometimes... odd off-by-1 expected results.
lround is C99 compliant and does not exist on Windows.
why not using the macro
#define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5))
?
Vincent
>
>
>
> Author: raster
> Date: 2011-10-10 23:06:11 -0700 (Mon, 10 Oct 2011)
> New Revision: 63978
> Trac: http://trac.enlightenment.org/e/changeset/63978
>
> Modified:
> trunk/evas/src/lib/canvas/evas_map.c
> trunk/evas/src/lib/canvas/evas_object_image.c
> trunk/evas/src/lib/canvas/evas_render.c
>
> Modified: trunk/evas/src/lib/canvas/evas_map.c
> ===
> --- trunk/evas/src/lib/canvas/evas_map.c 2011-10-11 05:12:06 UTC (rev
> 63977)
> +++ trunk/evas/src/lib/canvas/evas_map.c 2011-10-11 06:06:11 UTC (rev
> 63978)
> @@ -81,10 +81,10 @@
>
>p = obj->cur.map->points;
>p_end = p + obj->cur.map->count;
> - x1 = p->x;
> - x2 = p->x;
> - y1 = p->y;
> - y2 = p->y;
> + x1 = lround(p->x);
> + x2 = lround(p->x);
> + y1 = lround(p->y);
> + y2 = lround(p->y);
>p++;
>for (; p < p_end; p++)
> {
>
> Modified: trunk/evas/src/lib/canvas/evas_object_image.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_image.c 2011-10-11 05:12:06 UTC
> (rev 63977)
> +++ trunk/evas/src/lib/canvas/evas_object_image.c 2011-10-11 06:06:11 UTC
> (rev 63978)
> @@ -2,6 +2,7 @@
> #include
> #include
> #include
> +#include
>
> #include "evas_common.h"
> #include "evas_private.h"
> @@ -2887,14 +2888,14 @@
> // draw geom +x +y
> for (; p < p_end; p++, pt++)
>{
> - pt->x = (p->x + (double)x) * FP1;
> - pt->y = (p->y + (double)y) * FP1;
> - pt->z = (p->z) * FP1;
> + pt->x = (lround(p->x) + x) * FP1;
> + pt->y = (lround(p->y) + y) * FP1;
> + pt->z = (lround(p->z)) * FP1;
> pt->fx = p->px;
> pt->fy = p->py;
> pt->fz = p->z;
> - pt->u = ((p->u * imagew) / uvw) * FP1;
> - pt->v = ((p->v * imageh) / uvh) * FP1;
> + pt->u = ((lround(p->u) * imagew) / uvw) * FP1;
> + pt->v = ((lround(p->v) * imageh) / uvh) * FP1;
> if (pt->u < 0) pt->u = 0;
> else if (pt->u > (imagew * FP1)) pt->u = (imagew * FP1);
> if (pt->v < 0) pt->v = 0;
>
> Modified: trunk/evas/src/lib/canvas/evas_render.c
> ===
> --- trunk/evas/src/lib/canvas/evas_render.c 2011-10-11 05:12:06 UTC (rev
> 63977)
> +++ trunk/evas/src/lib/canvas/evas_render.c 2011-10-11 06:06:11 UTC (rev
> 63978)
> @@ -1,5 +1,6 @@
> #include "evas_common.h"
> #include "evas_private.h"
> +#include
>
> // debug rendering
> /* #define REND_DGB 1 */
> @@ -911,14 +912,14 @@
> pt = pts;
> for (; p < p_end; p++, pt++)
> {
> - pt->x = (p->x + (double)off_x) * FP1;
> - pt->y = (p->y + (double)off_y) * FP1;
> - pt->z = (p->z) * FP1;
> + pt->x = (lround(p->x) + off_x) * FP1;
> + pt->y = (lround(p->y) + off_y) * FP1;
> + pt->z = (lround(p->z)) * FP1;
> pt->fx = p->px;
> pt->fy = p->py;
> pt->fz = p->z;
> - pt->u = p->u * FP1;
> - pt->v = p->v * FP1;
> + pt->u = lround(p->u) * FP1;
> + pt->v = lround(p->v) * FP1;
> if (pt->u < 0) pt->u = 0;
> else if (pt->u > (sw * FP1)) pt->u = (sw * FP1);
> if (pt->v < 0) pt->v = 0;
>
>
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
Zero parameters before checking otherwise it will not touch them and
on failure caller will get garbage
--Gustavo
Sent from my iPhone
On 29/08/2011, at 08:40, Enlightenment SVN wrote:
> Log:
> dont need ti check priv - macro did it anyway
>
>
>
> Author: raster
> Date: 2011-08-29 04:39:43 -0700 (Mon, 29 Aug 2011)
> New Revision: 62941
> Trac: http://trac.enlightenment.org/e/changeset/62941
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_grid.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_grid.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_grid.c2011-08-29 11:28:43 UTC
> (rev 62940)
> +++ trunk/evas/src/lib/canvas/evas_object_grid.c2011-08-29 11:39:43 UTC
> (rev 62941)
> @@ -267,16 +267,8 @@
> evas_object_grid_size_get(const Evas_Object *o, int *w, int *h)
> {
>EVAS_OBJECT_GRID_DATA_GET_OR_RETURN(o, priv);
> - if (priv)
> - {
> -if (w) *w = priv->size.w;
> -if (h) *h = priv->size.h;
> - }
> - else
> - {
> -if (w) *w = 0;
> -if (h) *h = 0;
> - }
> + if (w) *w = priv->size.w;
> + if (h) *h = priv->size.h;
> }
>
> EAPI Eina_Bool
>
>
> --
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/gif
On Thu, 11 Aug 2011 19:34:34 -0700 "Enlightenment SVN" wrote: > Log: > how about you actuallyl fix the code correctly rather than break it? > > > > Author: raster > Date: 2011-08-11 19:34:34 -0700 (Thu, 11 Aug 2011) > New Revision: 62369 > Trac: http://trac.enlightenment.org/e/changeset/62369 > > Modified: > trunk/evas/src/modules/loaders/gif/evas_image_load_gif.c > evidently the hilarity of my commits was lost to everyone but me -- Mike Blumenkrantz Zentific: Coding in binary since '10. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On 08/08/11 17:45, Vincent Torri wrote: > is it really 'start' and not 'tmp' that should be usedd in > FcPatternAddString() ? Nice catch, fixed. -- Tom. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Mon, 8 Aug 2011, Enlightenment SVN wrote:
> Log:
> strndup--!
>
>
>
> Author: raster
> Date: 2011-08-08 07:40:33 -0700 (Mon, 08 Aug 2011)
> New Revision: 62206
> Trac: http://trac.enlightenment.org/e/changeset/62206
>
> Modified:
> trunk/evas/src/lib/canvas/evas_font_dir.c
>
> Modified: trunk/evas/src/lib/canvas/evas_font_dir.c
> ===
> --- trunk/evas/src/lib/canvas/evas_font_dir.c 2011-08-08 14:36:02 UTC (rev
> 62205)
> +++ trunk/evas/src/lib/canvas/evas_font_dir.c 2011-08-08 14:40:33 UTC (rev
> 62206)
> @@ -715,10 +715,10 @@
> end = strchr(start, ',');
> if (end)
> {
> - char *tmp;
> - tmp = strndup(start, end - start);
> + char *tmp = alloca((end - start) + 1);
> + strncpy(tmp, start, end - start);
> + tmp[end - start] = 0;
>FcPatternAddString (p_nm, FC_FAMILY, (FcChar8*) start);
is it really 'start' and not 'tmp' that should be usedd in
FcPatternAddString() ?
Vincent
> - free(tmp);
> }
> else
> {
>
>
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/cache
On Fri, 3 Jun 2011 00:33:37 -0300 Rafael Antognolli
said:
well color me pretty. i forgot about this email... found it.. and fixed in svn
now :)
> On Thu, Jun 2, 2011 at 4:09 AM, Cedric BAIL wrote:
> > On Wed, Jun 1, 2011 at 9:27 PM, Rafael Antognolli
> > wrote:
> >> On Thu, Sep 9, 2010 at 4:08 AM, Enlightenment SVN
> >> wrote:
> >>> Log:
> >>> lots of cleanups... actually tested! :)
> >>>
> >>>
> >>> Author: raster
> >>> Date: 2010-09-09 00:08:10 -0700 (Thu, 09 Sep 2010)
> >>> New Revision: 52030
> >>
> >>> static void
> >>> -_evas_preload_thread_end(Evas_Preload_Pthread_Data *pth)
> >>> +_evas_preload_thread_end(void *data)
> >>> {
> >>> - Evas_Preload_Pthread_Data *p;
> >>> + Evas_Preload_Pthread_Data *pth = data;
> >>> + Evas_Preload_Pthread_Data *p = NULL;
> >>>
> >>> - if (pthread_join(pth->thread, (void **) &p) != 0)
> >>> - return ;
> >>> -
> >>> - _evas_preload_thread = eina_list_remove(_evas_preload_thread, pth);
> >>> + if (pthread_join(pth->thread, (void **)&p) != 0) free(p);
> >>> }
> >>
> >> Hello raster, I know this is old, but I can't understand it... why do
> >> you only free the data struct on pthread_join error? Shouldn't you
> >> free it always?
> >>
> >> I can always get leaks on almost every call that I'm doing to
> >> edje_object_preload() on my program. I can send you a test case if
> >> necessary...
> >
> > Test case ! Test case ! Send it ! Send it !
>
> Test case attached. It leaks for every thread started for preload.
> Just give images as arguments in the command line. It should leak
> something like this:
>
> ==10047== 64 bytes in 8 blocks are definitely lost in loss record 44 of 78
> ==10047==at 0x4C267CE: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==10047==by 0x5302327: evas_preload_thread_run (evas_preload.c:197)
> ==10047==by 0x52FE624: _evas_cache_image_entry_preload_add
> (evas_cache_image.c:475)
> ==10047==by 0x5300199: evas_cache_image_preload_data
> (evas_cache_image.c:1270)
> ==10047==by 0xAE06CB6: ???
> ==10047==by 0x52AEF16: evas_object_image_preload
> (evas_object_image.c:1013) ==10047==by 0x400EAF: _image_preloaded_cb
> (test-evas-preload.c:29) ==10047==by 0x52A06E6:
> evas_object_event_callback_call (evas_callbacks.c:222)
> ==10047==by 0x52BC270: evas_object_inform_call_image_preloaded
> (evas_object_inform.c:68)
> ==10047==by 0x52FE3EA: _evas_cache_image_async_end
> (evas_cache_image.c:419) ==10047==by 0x5301FC1: _evas_preload_thread_done
> (evas_preload.c:70) ==10047==by 0x52F72D1: evas_async_events_process
> (evas_async_events.c:90)
>
>
> --
> Rafael Antognolli
> ProFUSION embedded systems
> http://profusion.mobi
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/software_x11
On Fri, 17 Jun 2011 22:45:10 +0900 Daniel Juyung Seo
said:
:-P~
> wow. it was so quick reply :)
>
> Daniel Juyung Seo (SeoZ)
> On Jun 17, 2011 6:01 PM, "Carsten Haitzler" wrote:
> >
> > On Thu, 21 Apr 2011 22:01:40 +0900 Daniel Juyung Seo >
> > said:
> >
> > yes it is :)
> >
> > > Hi Raster,
> > > Is this change related to our discussion?
> > >
> > > Daniel Juyung Seo (SeoZ)
> > > On Apr 21, 2011 9:34 PM, "Enlightenment SVN" >
> > > wrote:
> > > > Log:
> > > > add in lots of ptr checks to sw-x11 outbut code... this may only
> > > > happen if we ran out of mem and mallocs failed... but we can avoid a
> > > > crash.
> > > >
> > > >
> > > >
> > > > Author: raster
> > > > Date: 2011-04-21 05:33:35 -0700 (Thu, 21 Apr 2011)
> > > > New Revision: 58797
> > > > Trac: http://trac.enlightenment.org/e/changeset/58797
> > > >
> > > > Modified:
> > > > trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > > trunk/evas/src/modules/engines/software_x11/evas_xlib_buffer.c
> > > trunk/evas/src/modules/engines/software_x11/evas_xlib_outbuf.c
> > > >
> > > > Modified:
> trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > > > ===
> > > > --- trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > > 2011-04-21 12:22:07 UTC (rev 58796)
> > > > +++ trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > > 2011-04-21 12:33:35 UTC (rev 58797)
> > > > @@ -40,7 +40,6 @@
> > > > int lbytes;
> > > > int bpp;
> > > >
> > > > -// return evas_software_xcb_x_output_buffer_new(d, v, depth, w, h,
> shm,
> > > data);
> > > > if (!shm)
> > > > return evas_software_xcb_x_output_buffer_new(conn, depth, w, h, shm,
> > > data);
> > > > if (depth > 1)
> > > > @@ -92,7 +91,6 @@
> > > > static void
> > > > _unfind_xcbob(Xcb_Output_Buffer *xcbob, int sync)
> > > > {
> > > > -// evas_software_xcb_x_output_buffer_free(xcbob, sync); return;
> > > > if (xcbob->shm_info)
> > > > {
> > > > shmpool = eina_list_prepend(shmpool, xcbob);
> > > > @@ -398,8 +396,14 @@
> > > > Eina_Rectangle *rect;
> > > >
> > > > RECTS_CLIP_TO_RECT(x, y, w, h, 0, 0, buf->w, buf->h);
> > > > + obr = calloc(1, sizeof(Outbuf_Region));
> > > > + if (!obr) return NULL;
> > > > rect = eina_rectangle_new(x, y, w, h);
> > > > - if (!rect) return NULL;
> > > > + if (!rect)
> > > > + {
> > > > + free(obr);
> > > > + return NULL;
> > > > + }
> > > >
> > > > buf->priv.onebuf_regions = eina_list_append(buf->priv.onebuf_regions,
> > > rect);
> > > > if (buf->priv.onebuf)
> > > > @@ -416,7 +420,6 @@
> > > > }
> > > > return buf->priv.onebuf;
> > > > }
> > > > - obr = calloc(1, sizeof(Outbuf_Region));
> > > > obr->x = 0;
> > > > obr->y = 0;
> > > > obr->w = buf->w;
> > > > @@ -439,21 +442,37 @@
> > > > buf->w, buf->h,
> > > > use_shm,
> > > > NULL);
> > > > + if (!obr->xcbob)
> > > > + {
> > > > + free(obr);
> > > > + return NULL;
> > > > + }
> > > > im = (RGBA_Image *)
> evas_cache_image_data(evas_common_image_cache_get(),
> > > > buf->w, buf->h,
> > > > (DATA32 *)evas_software_xcb_x_output_buffer_data(obr->xcbob, &bpl),
> > > > alpha, EVAS_COLORSPACE_ARGB);
> > > > - im->extended_info = obr;
> > > > - if (buf->priv.x11.xcb.mask)
> > > > - obr->mxcbob =
> > > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > > - 1,
> > > > - buf->w, buf->h,
> > > > - use_shm,
> > > > - NULL);
> > > > + if (!im)
> > > > + {
> > > > + evas_software_xcb_x_output_buffer_free(obr->xcbob, 0);
> > > > + free(obr);
> > > > + return NULL;
> > > > + }
> > > > + im->extended_info = obr;
> > > > + if (buf->priv.x11.xcb.mask)
> > > > + obr->mxcbob =
> > > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > > + 1,
> > > > + buf->w, buf->h,
> > > > + use_shm,
> > > > + NULL);
> > > > }
> > > > else
> > > > {
> > > > im = (RGBA_Image *)
> evas_cache_image_empty(evas_common_image_cache_get());
> > > > + if (!im)
> > > > + {
> > > > + free(obr);
> > > > + return NULL;
> > > > + }
> > > > im->cache_entry.flags.alpha |= alpha ? 1 : 0;
> > > > evas_cache_image_surface_alloc(&im->cache_entry, buf->w, buf->h);
> > > > im->extended_info = obr;
> > > > @@ -464,6 +483,12 @@
> > > > buf->w, buf->h,
> > > > use_shm,
> > > > NULL);
> > > > + if (!obr->xcbob)
> > > > + {
> > > > + evas_cache_image_drop(&im->cache_entry);
> > > > + free(obr);
> > > > + return NULL;
> > > > + }
> > > > if (buf->priv.x11.xcb.mask)
> > > > obr->mxcbob =
> > > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > > 1,
> > > > @@ -478,6 +503,12 @@
> > > > buf->h, buf->w,
> > > > use_shm,
> > > > NULL);
> > > > + if (!obr->xcbob)
> > > > + {
> > > > + evas_cache_image_drop(&im->cache_entry);
> > > > + free(obr);
> > > > + return NULL;
> > > > + }
> > > > if (buf->priv.x11.xcb.mask)
> > > > obr->mxcbob =
> > > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > > 1,
> > > > @@ -488,9 +519,11 @@
> > > > }
> > > > /* FIXME: We should be able to remove this memset, but somewhere in
> t
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/software_x11
wow. it was so quick reply :)
Daniel Juyung Seo (SeoZ)
On Jun 17, 2011 6:01 PM, "Carsten Haitzler" wrote:
>
> On Thu, 21 Apr 2011 22:01:40 +0900 Daniel Juyung Seo
> said:
>
> yes it is :)
>
> > Hi Raster,
> > Is this change related to our discussion?
> >
> > Daniel Juyung Seo (SeoZ)
> > On Apr 21, 2011 9:34 PM, "Enlightenment SVN"
> > wrote:
> > > Log:
> > > add in lots of ptr checks to sw-x11 outbut code... this may only
> > > happen if we ran out of mem and mallocs failed... but we can avoid a
> > > crash.
> > >
> > >
> > >
> > > Author: raster
> > > Date: 2011-04-21 05:33:35 -0700 (Thu, 21 Apr 2011)
> > > New Revision: 58797
> > > Trac: http://trac.enlightenment.org/e/changeset/58797
> > >
> > > Modified:
> > > trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > trunk/evas/src/modules/engines/software_x11/evas_xlib_buffer.c
> > trunk/evas/src/modules/engines/software_x11/evas_xlib_outbuf.c
> > >
> > > Modified:
trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > > ===
> > > --- trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > 2011-04-21 12:22:07 UTC (rev 58796)
> > > +++ trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > 2011-04-21 12:33:35 UTC (rev 58797)
> > > @@ -40,7 +40,6 @@
> > > int lbytes;
> > > int bpp;
> > >
> > > -// return evas_software_xcb_x_output_buffer_new(d, v, depth, w, h,
shm,
> > data);
> > > if (!shm)
> > > return evas_software_xcb_x_output_buffer_new(conn, depth, w, h, shm,
> > data);
> > > if (depth > 1)
> > > @@ -92,7 +91,6 @@
> > > static void
> > > _unfind_xcbob(Xcb_Output_Buffer *xcbob, int sync)
> > > {
> > > -// evas_software_xcb_x_output_buffer_free(xcbob, sync); return;
> > > if (xcbob->shm_info)
> > > {
> > > shmpool = eina_list_prepend(shmpool, xcbob);
> > > @@ -398,8 +396,14 @@
> > > Eina_Rectangle *rect;
> > >
> > > RECTS_CLIP_TO_RECT(x, y, w, h, 0, 0, buf->w, buf->h);
> > > + obr = calloc(1, sizeof(Outbuf_Region));
> > > + if (!obr) return NULL;
> > > rect = eina_rectangle_new(x, y, w, h);
> > > - if (!rect) return NULL;
> > > + if (!rect)
> > > + {
> > > + free(obr);
> > > + return NULL;
> > > + }
> > >
> > > buf->priv.onebuf_regions = eina_list_append(buf->priv.onebuf_regions,
> > rect);
> > > if (buf->priv.onebuf)
> > > @@ -416,7 +420,6 @@
> > > }
> > > return buf->priv.onebuf;
> > > }
> > > - obr = calloc(1, sizeof(Outbuf_Region));
> > > obr->x = 0;
> > > obr->y = 0;
> > > obr->w = buf->w;
> > > @@ -439,21 +442,37 @@
> > > buf->w, buf->h,
> > > use_shm,
> > > NULL);
> > > + if (!obr->xcbob)
> > > + {
> > > + free(obr);
> > > + return NULL;
> > > + }
> > > im = (RGBA_Image *)
evas_cache_image_data(evas_common_image_cache_get(),
> > > buf->w, buf->h,
> > > (DATA32 *)evas_software_xcb_x_output_buffer_data(obr->xcbob, &bpl),
> > > alpha, EVAS_COLORSPACE_ARGB);
> > > - im->extended_info = obr;
> > > - if (buf->priv.x11.xcb.mask)
> > > - obr->mxcbob =
> > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > - 1,
> > > - buf->w, buf->h,
> > > - use_shm,
> > > - NULL);
> > > + if (!im)
> > > + {
> > > + evas_software_xcb_x_output_buffer_free(obr->xcbob, 0);
> > > + free(obr);
> > > + return NULL;
> > > + }
> > > + im->extended_info = obr;
> > > + if (buf->priv.x11.xcb.mask)
> > > + obr->mxcbob =
> > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > + 1,
> > > + buf->w, buf->h,
> > > + use_shm,
> > > + NULL);
> > > }
> > > else
> > > {
> > > im = (RGBA_Image *)
evas_cache_image_empty(evas_common_image_cache_get());
> > > + if (!im)
> > > + {
> > > + free(obr);
> > > + return NULL;
> > > + }
> > > im->cache_entry.flags.alpha |= alpha ? 1 : 0;
> > > evas_cache_image_surface_alloc(&im->cache_entry, buf->w, buf->h);
> > > im->extended_info = obr;
> > > @@ -464,6 +483,12 @@
> > > buf->w, buf->h,
> > > use_shm,
> > > NULL);
> > > + if (!obr->xcbob)
> > > + {
> > > + evas_cache_image_drop(&im->cache_entry);
> > > + free(obr);
> > > + return NULL;
> > > + }
> > > if (buf->priv.x11.xcb.mask)
> > > obr->mxcbob =
> > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > 1,
> > > @@ -478,6 +503,12 @@
> > > buf->h, buf->w,
> > > use_shm,
> > > NULL);
> > > + if (!obr->xcbob)
> > > + {
> > > + evas_cache_image_drop(&im->cache_entry);
> > > + free(obr);
> > > + return NULL;
> > > + }
> > > if (buf->priv.x11.xcb.mask)
> > > obr->mxcbob =
> > evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > > 1,
> > > @@ -488,9 +519,11 @@
> > > }
> > > /* FIXME: We should be able to remove this memset, but somewhere in
the
> > process
> > > we copy too much to the destination surface and some area are not
cleaned
> > before copy. */
> > > - if (alpha)
> > > - /* FIXME: faster memset! */
> > > - memset(im->image.data, 0, w * h * sizeof(DATA32));
> > > + if ((alpha) && (im->image.data))
> > > + {
> > > + /* FIXME: faster memset! */
> > > + memset(im->image.data, 0, w * h * sizeof(DATA32));
> > > + }
> > >
> > > buf-
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/software_x11
On Thu, 21 Apr 2011 22:01:40 +0900 Daniel Juyung Seo
said:
yes it is :)
> Hi Raster,
> Is this change related to our discussion?
>
> Daniel Juyung Seo (SeoZ)
> On Apr 21, 2011 9:34 PM, "Enlightenment SVN"
> wrote:
> > Log:
> > add in lots of ptr checks to sw-x11 outbut code... this may only
> > happen if we ran out of mem and mallocs failed... but we can avoid a
> > crash.
> >
> >
> >
> > Author: raster
> > Date: 2011-04-21 05:33:35 -0700 (Thu, 21 Apr 2011)
> > New Revision: 58797
> > Trac: http://trac.enlightenment.org/e/changeset/58797
> >
> > Modified:
> > trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> trunk/evas/src/modules/engines/software_x11/evas_xlib_buffer.c
> trunk/evas/src/modules/engines/software_x11/evas_xlib_outbuf.c
> >
> > Modified: trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> > ===
> > --- trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> 2011-04-21 12:22:07 UTC (rev 58796)
> > +++ trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> 2011-04-21 12:33:35 UTC (rev 58797)
> > @@ -40,7 +40,6 @@
> > int lbytes;
> > int bpp;
> >
> > -// return evas_software_xcb_x_output_buffer_new(d, v, depth, w, h, shm,
> data);
> > if (!shm)
> > return evas_software_xcb_x_output_buffer_new(conn, depth, w, h, shm,
> data);
> > if (depth > 1)
> > @@ -92,7 +91,6 @@
> > static void
> > _unfind_xcbob(Xcb_Output_Buffer *xcbob, int sync)
> > {
> > -// evas_software_xcb_x_output_buffer_free(xcbob, sync); return;
> > if (xcbob->shm_info)
> > {
> > shmpool = eina_list_prepend(shmpool, xcbob);
> > @@ -398,8 +396,14 @@
> > Eina_Rectangle *rect;
> >
> > RECTS_CLIP_TO_RECT(x, y, w, h, 0, 0, buf->w, buf->h);
> > + obr = calloc(1, sizeof(Outbuf_Region));
> > + if (!obr) return NULL;
> > rect = eina_rectangle_new(x, y, w, h);
> > - if (!rect) return NULL;
> > + if (!rect)
> > + {
> > + free(obr);
> > + return NULL;
> > + }
> >
> > buf->priv.onebuf_regions = eina_list_append(buf->priv.onebuf_regions,
> rect);
> > if (buf->priv.onebuf)
> > @@ -416,7 +420,6 @@
> > }
> > return buf->priv.onebuf;
> > }
> > - obr = calloc(1, sizeof(Outbuf_Region));
> > obr->x = 0;
> > obr->y = 0;
> > obr->w = buf->w;
> > @@ -439,21 +442,37 @@
> > buf->w, buf->h,
> > use_shm,
> > NULL);
> > + if (!obr->xcbob)
> > + {
> > + free(obr);
> > + return NULL;
> > + }
> > im = (RGBA_Image *) evas_cache_image_data(evas_common_image_cache_get(),
> > buf->w, buf->h,
> > (DATA32 *)evas_software_xcb_x_output_buffer_data(obr->xcbob, &bpl),
> > alpha, EVAS_COLORSPACE_ARGB);
> > - im->extended_info = obr;
> > - if (buf->priv.x11.xcb.mask)
> > - obr->mxcbob =
> evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > - 1,
> > - buf->w, buf->h,
> > - use_shm,
> > - NULL);
> > + if (!im)
> > + {
> > + evas_software_xcb_x_output_buffer_free(obr->xcbob, 0);
> > + free(obr);
> > + return NULL;
> > + }
> > + im->extended_info = obr;
> > + if (buf->priv.x11.xcb.mask)
> > + obr->mxcbob =
> evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > + 1,
> > + buf->w, buf->h,
> > + use_shm,
> > + NULL);
> > }
> > else
> > {
> > im = (RGBA_Image *) evas_cache_image_empty(evas_common_image_cache_get());
> > + if (!im)
> > + {
> > + free(obr);
> > + return NULL;
> > + }
> > im->cache_entry.flags.alpha |= alpha ? 1 : 0;
> > evas_cache_image_surface_alloc(&im->cache_entry, buf->w, buf->h);
> > im->extended_info = obr;
> > @@ -464,6 +483,12 @@
> > buf->w, buf->h,
> > use_shm,
> > NULL);
> > + if (!obr->xcbob)
> > + {
> > + evas_cache_image_drop(&im->cache_entry);
> > + free(obr);
> > + return NULL;
> > + }
> > if (buf->priv.x11.xcb.mask)
> > obr->mxcbob =
> evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > 1,
> > @@ -478,6 +503,12 @@
> > buf->h, buf->w,
> > use_shm,
> > NULL);
> > + if (!obr->xcbob)
> > + {
> > + evas_cache_image_drop(&im->cache_entry);
> > + free(obr);
> > + return NULL;
> > + }
> > if (buf->priv.x11.xcb.mask)
> > obr->mxcbob =
> evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> > 1,
> > @@ -488,9 +519,11 @@
> > }
> > /* FIXME: We should be able to remove this memset, but somewhere in the
> process
> > we copy too much to the destination surface and some area are not cleaned
> before copy. */
> > - if (alpha)
> > - /* FIXME: faster memset! */
> > - memset(im->image.data, 0, w * h * sizeof(DATA32));
> > + if ((alpha) && (im->image.data))
> > + {
> > + /* FIXME: faster memset! */
> > + memset(im->image.data, 0, w * h * sizeof(DATA32));
> > + }
> >
> > buf->priv.onebuf = im;
> > return im;
> > @@ -498,6 +531,7 @@
> >
> >
> > obr = calloc(1, sizeof(Outbuf_Region));
> > + if (!obr) return NULL;
> > obr->x = x;
> > obr->y = y;
> > obr->w = w;
> > @@ -526,27 +560,37 @@
> > w, h,
> > use_shm,
> > NULL);
> > - im = (RGBA_Image *) evas_cache_image_data(evas_common_image_cache_get(),
> > - w, h,
> > - (DATA32 *) evas_software_xcb_x_output_buffer_data(obr->xcbob, &bpl),
> > - alpha, EVAS_COLORSPACE_A
Re: [E-devel] E SVN: raster trunk/evas/src/lib/cache
On Thu, Jun 2, 2011 at 4:09 AM, Cedric BAIL wrote:
> On Wed, Jun 1, 2011 at 9:27 PM, Rafael Antognolli
> wrote:
>> On Thu, Sep 9, 2010 at 4:08 AM, Enlightenment SVN
>> wrote:
>>> Log:
>>> lots of cleanups... actually tested! :)
>>>
>>>
>>> Author: raster
>>> Date: 2010-09-09 00:08:10 -0700 (Thu, 09 Sep 2010)
>>> New Revision: 52030
>>
>>> static void
>>> -_evas_preload_thread_end(Evas_Preload_Pthread_Data *pth)
>>> +_evas_preload_thread_end(void *data)
>>> {
>>> - Evas_Preload_Pthread_Data *p;
>>> + Evas_Preload_Pthread_Data *pth = data;
>>> + Evas_Preload_Pthread_Data *p = NULL;
>>>
>>> - if (pthread_join(pth->thread, (void **) &p) != 0)
>>> - return ;
>>> -
>>> - _evas_preload_thread = eina_list_remove(_evas_preload_thread, pth);
>>> + if (pthread_join(pth->thread, (void **)&p) != 0) free(p);
>>> }
>>
>> Hello raster, I know this is old, but I can't understand it... why do
>> you only free the data struct on pthread_join error? Shouldn't you
>> free it always?
>>
>> I can always get leaks on almost every call that I'm doing to
>> edje_object_preload() on my program. I can send you a test case if
>> necessary...
>
> Test case ! Test case ! Send it ! Send it !
Test case attached. It leaks for every thread started for preload.
Just give images as arguments in the command line. It should leak
something like this:
==10047== 64 bytes in 8 blocks are definitely lost in loss record 44 of 78
==10047==at 0x4C267CE: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==10047==by 0x5302327: evas_preload_thread_run (evas_preload.c:197)
==10047==by 0x52FE624: _evas_cache_image_entry_preload_add
(evas_cache_image.c:475)
==10047==by 0x5300199: evas_cache_image_preload_data
(evas_cache_image.c:1270)
==10047==by 0xAE06CB6: ???
==10047==by 0x52AEF16: evas_object_image_preload (evas_object_image.c:1013)
==10047==by 0x400EAF: _image_preloaded_cb (test-evas-preload.c:29)
==10047==by 0x52A06E6: evas_object_event_callback_call
(evas_callbacks.c:222)
==10047==by 0x52BC270: evas_object_inform_call_image_preloaded
(evas_object_inform.c:68)
==10047==by 0x52FE3EA: _evas_cache_image_async_end (evas_cache_image.c:419)
==10047==by 0x5301FC1: _evas_preload_thread_done (evas_preload.c:70)
==10047==by 0x52F72D1: evas_async_events_process (evas_async_events.c:90)
--
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi
#include
#include
#include
#define WIDTH 800
#define HEIGHT 600
static Evas_Object **pictures = NULL;
static int npictures = 0;
static int pic = 0;
static void
_image_preloaded_cb(void *data, Evas *e, Evas_Object *o, void *event_info)
{
evas_object_show(o);
printf("loading pic %d of %d\n", pic + 1, npictures);
if (++pic >= npictures) {
ecore_main_loop_quit();
return;
}
evas_object_image_preload(pictures[pic], EINA_FALSE);
}
int
main(int argc, const char *argv[])
{
Ecore_Evas *ee;
Evas *e;
Ecore_Timer *timer = NULL;
Evas_Object *picture;
int i;
if (argc <= 1)
return 0;
evas_init();
ecore_init();
ecore_evas_init();
ee = ecore_evas_new(NULL, 0, 0, WIDTH, HEIGHT, NULL);
e = ecore_evas_get(ee);
ecore_evas_show(ee);
printf("trying to load %d images\n bytes = %zd\n", argc - 1, sizeof(Evas_Object *) * (argc - 1));
pictures = malloc(sizeof(Evas_Object *) * (argc - 1));
npictures = argc - 1;
for (i = 1; i < argc; i++) {
picture = evas_object_image_filled_add(e);
evas_object_move(picture, 0, 0);
evas_object_resize(picture, WIDTH, HEIGHT);
evas_object_hide(picture);
printf("loading: '%s'\n", argv[i]);
evas_object_image_file_set(picture, argv[i], "");
evas_object_event_callback_add(picture, EVAS_CALLBACK_IMAGE_PRELOADED, _image_preloaded_cb, NULL);
pictures[i - 1] = picture;
}
evas_object_image_preload(pictures[pic], EINA_FALSE);
ecore_main_loop_begin();
ecore_evas_free(ee);
free(pictures);
ecore_evas_shutdown();
ecore_shutdown();
evas_shutdown();
return 0;
}
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2 ___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/cache
On Wed, Jun 1, 2011 at 9:27 PM, Rafael Antognolli
wrote:
> On Thu, Sep 9, 2010 at 4:08 AM, Enlightenment SVN
> wrote:
>> Log:
>> lots of cleanups... actually tested! :)
>>
>>
>> Author: raster
>> Date: 2010-09-09 00:08:10 -0700 (Thu, 09 Sep 2010)
>> New Revision: 52030
>
>> static void
>> -_evas_preload_thread_end(Evas_Preload_Pthread_Data *pth)
>> +_evas_preload_thread_end(void *data)
>> {
>> - Evas_Preload_Pthread_Data *p;
>> + Evas_Preload_Pthread_Data *pth = data;
>> + Evas_Preload_Pthread_Data *p = NULL;
>>
>> - if (pthread_join(pth->thread, (void **) &p) != 0)
>> - return ;
>> -
>> - _evas_preload_thread = eina_list_remove(_evas_preload_thread, pth);
>> + if (pthread_join(pth->thread, (void **)&p) != 0) free(p);
>> }
>
> Hello raster, I know this is old, but I can't understand it... why do
> you only free the data struct on pthread_join error? Shouldn't you
> free it always?
>
> I can always get leaks on almost every call that I'm doing to
> edje_object_preload() on my program. I can send you a test case if
> necessary...
Test case ! Test case ! Send it ! Send it !
--
Cedric BAIL
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/cache
On Thu, Sep 9, 2010 at 4:08 AM, Enlightenment SVN
wrote:
> Log:
> lots of cleanups... actually tested! :)
>
>
> Author: raster
> Date: 2010-09-09 00:08:10 -0700 (Thu, 09 Sep 2010)
> New Revision: 52030
> static void
> -_evas_preload_thread_end(Evas_Preload_Pthread_Data *pth)
> +_evas_preload_thread_end(void *data)
> {
> - Evas_Preload_Pthread_Data *p;
> + Evas_Preload_Pthread_Data *pth = data;
> + Evas_Preload_Pthread_Data *p = NULL;
>
> - if (pthread_join(pth->thread, (void **) &p) != 0)
> - return ;
> -
> - _evas_preload_thread = eina_list_remove(_evas_preload_thread, pth);
> + if (pthread_join(pth->thread, (void **)&p) != 0) free(p);
> }
Hello raster, I know this is old, but I can't understand it... why do
you only free the data struct on pthread_join error? Shouldn't you
free it always?
I can always get leaks on almost every call that I'm doing to
edje_object_preload() on my program. I can send you a test case if
necessary...
--
Rafael Antognolli
ProFUSION embedded systems
http://profusion.mobi
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas
On Tue, 26 Apr 2011 08:17:27 +0200 (CEST) Vincent Torri said: not my actual manual pages on a linux machine: SHM_OPEN(3)Linux Programmer's Manual SHM_OPEN(3) NAME shm_open, shm_unlink - Create/open or unlink POSIX shared memory objects SYNOPSIS #include #include /* For mode constants */ #include/* For O_* constants */ int shm_open(const char *name, int oflag, mode_t mode); int shm_unlink(const char *name); Link with -lrt. DESCRIPTION shm_open() creates and opens a new, or opens an existing, POSIX shared memory object. A POSIX shared memory object is in effect a handle which can be used by unrelated processes to mmap(2) the same region of shared memory. The shm_unlink() function performs the converse opera‐ tion, removing an object previously created by shm_open(). > > > On Mon, 25 Apr 2011, Enlightenment SVN wrote: > > > Log: > > use correct hdr in shm open check. > > > > > > > > Author: raster > > Date: 2011-04-25 22:12:25 -0700 (Mon, 25 Apr 2011) > > New Revision: 58917 > > Trac: http://trac.enlightenment.org/e/changeset/58917 > > > > Modified: > > trunk/evas/configure.ac > > > > Modified: trunk/evas/configure.ac > > === > > --- trunk/evas/configure.ac 2011-04-26 04:35:27 UTC (rev 58916) > > +++ trunk/evas/configure.ac 2011-04-26 05:12:25 UTC (rev 58917) > > @@ -484,7 +484,7 @@ > > AC_LINK_IFELSE( > >[AC_LANG_PROGRAM( > > [[ > > -#include > > +#include > > #include > > #include > > ]], > > http://linux.die.net/man/3/shm_open > > Vincent > > -- > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas
On Mon, 25 Apr 2011, Enlightenment SVN wrote: > Log: > use correct hdr in shm open check. > > > > Author: raster > Date: 2011-04-25 22:12:25 -0700 (Mon, 25 Apr 2011) > New Revision: 58917 > Trac: http://trac.enlightenment.org/e/changeset/58917 > > Modified: > trunk/evas/configure.ac > > Modified: trunk/evas/configure.ac > === > --- trunk/evas/configure.ac 2011-04-26 04:35:27 UTC (rev 58916) > +++ trunk/evas/configure.ac 2011-04-26 05:12:25 UTC (rev 58917) > @@ -484,7 +484,7 @@ > AC_LINK_IFELSE( >[AC_LANG_PROGRAM( > [[ > -#include > +#include > #include > #include > ]], http://linux.die.net/man/3/shm_open Vincent -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/software_x11
Hi Raster,
Is this change related to our discussion?
Daniel Juyung Seo (SeoZ)
On Apr 21, 2011 9:34 PM, "Enlightenment SVN"
wrote:
> Log:
> add in lots of ptr checks to sw-x11 outbut code... this may only
> happen if we ran out of mem and mallocs failed... but we can avoid a
> crash.
>
>
>
> Author: raster
> Date: 2011-04-21 05:33:35 -0700 (Thu, 21 Apr 2011)
> New Revision: 58797
> Trac: http://trac.enlightenment.org/e/changeset/58797
>
> Modified:
> trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
trunk/evas/src/modules/engines/software_x11/evas_xlib_buffer.c
trunk/evas/src/modules/engines/software_x11/evas_xlib_outbuf.c
>
> Modified: trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
> ===
> --- trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
2011-04-21 12:22:07 UTC (rev 58796)
> +++ trunk/evas/src/modules/engines/software_x11/evas_xcb_outbuf.c
2011-04-21 12:33:35 UTC (rev 58797)
> @@ -40,7 +40,6 @@
> int lbytes;
> int bpp;
>
> -// return evas_software_xcb_x_output_buffer_new(d, v, depth, w, h, shm,
data);
> if (!shm)
> return evas_software_xcb_x_output_buffer_new(conn, depth, w, h, shm,
data);
> if (depth > 1)
> @@ -92,7 +91,6 @@
> static void
> _unfind_xcbob(Xcb_Output_Buffer *xcbob, int sync)
> {
> -// evas_software_xcb_x_output_buffer_free(xcbob, sync); return;
> if (xcbob->shm_info)
> {
> shmpool = eina_list_prepend(shmpool, xcbob);
> @@ -398,8 +396,14 @@
> Eina_Rectangle *rect;
>
> RECTS_CLIP_TO_RECT(x, y, w, h, 0, 0, buf->w, buf->h);
> + obr = calloc(1, sizeof(Outbuf_Region));
> + if (!obr) return NULL;
> rect = eina_rectangle_new(x, y, w, h);
> - if (!rect) return NULL;
> + if (!rect)
> + {
> + free(obr);
> + return NULL;
> + }
>
> buf->priv.onebuf_regions = eina_list_append(buf->priv.onebuf_regions,
rect);
> if (buf->priv.onebuf)
> @@ -416,7 +420,6 @@
> }
> return buf->priv.onebuf;
> }
> - obr = calloc(1, sizeof(Outbuf_Region));
> obr->x = 0;
> obr->y = 0;
> obr->w = buf->w;
> @@ -439,21 +442,37 @@
> buf->w, buf->h,
> use_shm,
> NULL);
> + if (!obr->xcbob)
> + {
> + free(obr);
> + return NULL;
> + }
> im = (RGBA_Image *) evas_cache_image_data(evas_common_image_cache_get(),
> buf->w, buf->h,
> (DATA32 *)evas_software_xcb_x_output_buffer_data(obr->xcbob, &bpl),
> alpha, EVAS_COLORSPACE_ARGB);
> - im->extended_info = obr;
> - if (buf->priv.x11.xcb.mask)
> - obr->mxcbob =
evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> - 1,
> - buf->w, buf->h,
> - use_shm,
> - NULL);
> + if (!im)
> + {
> + evas_software_xcb_x_output_buffer_free(obr->xcbob, 0);
> + free(obr);
> + return NULL;
> + }
> + im->extended_info = obr;
> + if (buf->priv.x11.xcb.mask)
> + obr->mxcbob =
evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> + 1,
> + buf->w, buf->h,
> + use_shm,
> + NULL);
> }
> else
> {
> im = (RGBA_Image *) evas_cache_image_empty(evas_common_image_cache_get());
> + if (!im)
> + {
> + free(obr);
> + return NULL;
> + }
> im->cache_entry.flags.alpha |= alpha ? 1 : 0;
> evas_cache_image_surface_alloc(&im->cache_entry, buf->w, buf->h);
> im->extended_info = obr;
> @@ -464,6 +483,12 @@
> buf->w, buf->h,
> use_shm,
> NULL);
> + if (!obr->xcbob)
> + {
> + evas_cache_image_drop(&im->cache_entry);
> + free(obr);
> + return NULL;
> + }
> if (buf->priv.x11.xcb.mask)
> obr->mxcbob =
evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> 1,
> @@ -478,6 +503,12 @@
> buf->h, buf->w,
> use_shm,
> NULL);
> + if (!obr->xcbob)
> + {
> + evas_cache_image_drop(&im->cache_entry);
> + free(obr);
> + return NULL;
> + }
> if (buf->priv.x11.xcb.mask)
> obr->mxcbob =
evas_software_xcb_x_output_buffer_new(buf->priv.x11.xcb.conn,
> 1,
> @@ -488,9 +519,11 @@
> }
> /* FIXME: We should be able to remove this memset, but somewhere in the
process
> we copy too much to the destination surface and some area are not cleaned
before copy. */
> - if (alpha)
> - /* FIXME: faster memset! */
> - memset(im->image.data, 0, w * h * sizeof(DATA32));
> + if ((alpha) && (im->image.data))
> + {
> + /* FIXME: faster memset! */
> + memset(im->image.data, 0, w * h * sizeof(DATA32));
> + }
>
> buf->priv.onebuf = im;
> return im;
> @@ -498,6 +531,7 @@
>
>
> obr = calloc(1, sizeof(Outbuf_Region));
> + if (!obr) return NULL;
> obr->x = x;
> obr->y = y;
> obr->w = w;
> @@ -526,27 +560,37 @@
> w, h,
> use_shm,
> NULL);
> - im = (RGBA_Image *) evas_cache_image_data(evas_common_image_cache_get(),
> - w, h,
> - (DATA32 *) evas_software_xcb_x_output_buffer_data(obr->xcbob, &bpl),
> - alpha, EVAS_COLORSPACE_ARGB);
> - im->extended_info = obr;
> + if (!obr->xcbob)
> + {
> + free(obr);
> + return NULL;
> + }
> + im = (RGBA_Image *)evas_cache_image_data(evas_common_image_cache_get(),
> + w, h,
> + (DATA32 *) evas_software_xcb_x_output_buffer_data(obr->xcbob, &bpl),
> + alpha, EVAS_COLORSPACE_ARGB);
> + if (!im)
> + {
> + _unfind_xob(obr->xob, 0);
> + free(obr);
> + return NULL;
> + }
> + im->extended_info = obr;
> if (buf->priv.x1
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/gl_common/shader
On Thu, 21 Apr 2011 01:03:50 +1000 Brett Nash said: > On Wed, 2011-04-20 at 00:12 -0700, Enlightenment SVN wrote: > > Log: > > start fixing shader mess. at least add mask compile to scripts. need > > to do filters. > > Is there a summary of the method to do this somewhere? no - other than there being 2 scripts that are tiny and handle compiling the .shd files into respective src files used by the build. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/gl_common/shader
On Wed, 2011-04-20 at 00:12 -0700, Enlightenment SVN wrote: > Log: > start fixing shader mess. at least add mask compile to scripts. need > to do filters. Is there a summary of the method to do this somewhere? Regards, nash -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
On Tue, 2011-04-19 at 18:22 -0700, Enlightenment SVN wrote: > Log: > oh dear... way too many warnings. added a whole bunch of fixme's too > for later. I'll sort out the fixme's shortly. Just to be clear; the warnings are mostly unused params? Because it compiles cleanly for me[1], and my flags are -Wall and -Wextra. However I do set -Wno-sign-compare[2], and -Wno-unused-paramater Regards, nash [1] I checked, multiple times. [2] I do this because of otherwise enums nearly always give you the stupid unsigned vs signed comparison, and C gives you no portable way of avoiding it[3]. [3] The cast both sides isn't portable in the general case. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/gl_x11
On 03/20/2011 11:04 AM, Mike Blumenkrantz wrote:
> On Sun, 20 Mar 2011 01:48:30 -0700
> "Enlightenment SVN" wrote:
>> + if (!_evas_gl_x11_vi[screen]) return NULL;
>>
>> + if (screen>= MAXSCRN)
>> + {
>> +ERR("Screen #%i beyond the maximum # of supported screens (%i)",
>> +screen, MAXSCRN);
>> +return NULL;
>> + }
>> +
First access an array, then check index?
S.
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/gl_x11
On Sun, 20 Mar 2011 06:04:10 -0400 Mike Blumenkrantz said: > hey sorry for disappearing, having some crazy hw issues suddenly. I tested > this very briefly when I was able to get X up, and it "sort of works." the gl > ctx does init since I no longer get jeffdameth's error window, but rendering > on the second screen looks like it's failing; all I get is a blackish screen > which turns white whenever I try to open something on the screen. primary > screen works as expected. > > I'll be back in action tomorrow, gotta fix this stuff first though. hmmm... i highly suspect it may not allow sharing of textures and other resources between 2 screens. that really creates a major poopie-pants if that is the case. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/engines/gl_x11
On Sun, 20 Mar 2011 01:48:30 -0700
"Enlightenment SVN" wrote:
> Log:
> support multiple screens AT the same time... multiple gl contexts -
> one is created per screen #. max is 16 screens (0->15). dont know if
> this really works yet.
>
>
>
> Author: raster
> Date: 2011-03-20 01:48:30 -0700 (Sun, 20 Mar 2011)
> New Revision: 57912
> Trac: http://trac.enlightenment.org/e/changeset/57912
>
> Modified:
> trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
>
> Modified: trunk/evas/src/modules/engines/gl_x11/evas_x_main.c
> ===
> --- trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-20
> 06:51:13 UTC (rev 57911) +++
> trunk/evas/src/modules/engines/gl_x11/evas_x_main.c 2011-03-20
> 08:48:30 UTC (rev 57912) @@ -1,24 +1,26 @@ #include "evas_engine.h"
>
> +#define MAXSCRN 16
> +
> static Evas_GL_X11_Window *_evas_gl_x11_window = NULL;
>
> #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
> -static EGLContext context = EGL_NO_CONTEXT;
> +static EGLContext context [MAXSCRN] = {EGL_NO_CONTEXT};
> #else
> // FIXME: this will only work for 1 display connection (glx land can have >
> 1) -static GLXContext context = 0;
> -static GLXContext rgba_context = 0;
> -static GLXFBConfig fbconf = 0;
> -static GLXFBConfig rgba_fbconf = 0;
> +static GLXContext context [MAXSCRN] = {0};
> +static GLXContext rgba_context [MAXSCRN] = {0};
> +static GLXFBConfig fbconf [MAXSCRN] = {0};
> +static GLXFBConfig rgba_fbconf [MAXSCRN] = {0};
> #endif
>
> // fixme: something is up/wrong here - dont know what tho...
> -// #define NEWGL 1
> +//#define NEWGL 1
>
> -static XVisualInfo *_evas_gl_x11_vi = NULL;
> -static XVisualInfo *_evas_gl_x11_rgba_vi = NULL;
> -static Colormap _evas_gl_x11_cmap = 0;
> -static Colormap _evas_gl_x11_rgba_cmap = 0;
> +static XVisualInfo *_evas_gl_x11_vi[MAXSCRN] = {NULL};
> +static XVisualInfo *_evas_gl_x11_rgba_vi [MAXSCRN] = {NULL};
> +static Colormap _evas_gl_x11_cmap [MAXSCRN] = {0};
> +static Colormap _evas_gl_x11_rgba_cmap [MAXSCRN] = {0};
>
> static int win_count = 0;
>
> @@ -45,8 +47,15 @@
> XVisualInfo *vi_use;
> const GLubyte *vendor, *renderer, *version;
>
> - if (!_evas_gl_x11_vi) return NULL;
> + if (!_evas_gl_x11_vi[screen]) return NULL;
>
> + if (screen >= MAXSCRN)
> + {
> +ERR("Screen #%i beyond the maximum # of supported screens (%i)",
> +screen, MAXSCRN);
> +return NULL;
> + }
> +
> gw = calloc(1, sizeof(Evas_GL_X11_Window));
> if (!gw) return NULL;
>
> @@ -62,7 +71,7 @@
> gw->h = h;
> gw->rot = rot;
>
> - vi_use = _evas_gl_x11_vi;
> + vi_use = _evas_gl_x11_vi[gw->screen];
> if (gw->alpha)
> {
> #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
> @@ -72,17 +81,19 @@
>}
> #else
> #ifdef NEWGL
> +/*
> if (_evas_gl_x11_rgba_vi)
>{
> vi_use = _evas_gl_x11_rgba_vi;
>}
> + */
> #endif
> #endif
> }
> gw->visualinfo = vi_use;
>
> +#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
> // EGL / GLES
> -#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
> context_attrs[0] = EGL_CONTEXT_CLIENT_VERSION;
> context_attrs[1] = 2;
> context_attrs[2] = EGL_NONE;
> @@ -195,10 +206,10 @@
> eng_window_free(gw);
> return NULL;
> }
> - if (context == EGL_NO_CONTEXT)
> - context = eglCreateContext(gw->egl_disp, gw->egl_config, NULL,
> -context_attrs);
> - gw->egl_context[0] = context;
> + if (context[gw->screen] == EGL_NO_CONTEXT)
> + context[gw->screen] = eglCreateContext(gw->egl_disp, gw->egl_config,
> + NULL, context_attrs);
> + gw->egl_context[0] = context[gw->screen];
> if (gw->egl_context[0] == EGL_NO_CONTEXT)
> {
> ERR("eglCreateContext() fail. code=%#x", eglGetError());
> @@ -228,52 +239,56 @@
> fprintf(stderr, "renderer: %s\n", renderer);
> fprintf(stderr, "version: %s\n", version);
> }
> -// GLX
> #else
> - if (!context)
> +// GLX
> + if (!context[gw->screen])
> {
> #ifdef NEWGL
> +/*
> if (indirect)
> - context = glXCreateNewContext(gw->disp, fbconf,
> + context[gw->screen] = glXCreateNewContext(gw->disp,
> fbconf[gw->screen], GLX_RGBA_TYPE, NULL,
> GL_TRUE);
> else
> - context = glXCreateNewContext(gw->disp, fbconf,
> + context[gw->screen] = glXCreateNewContext(gw->disp,
> fbconf[gw->screen], GLX_RGBA_TYPE, NULL,
> GL_FALSE);
> + */
> #else
> if (indirect)
> - context = glXCreateContext(gw->disp, gw->visualinfo, NULL,
>
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/bmp
On Thu, Mar 10, 2011 at 8:11 PM, Enlightenment SVN
wrote:
> Log:
> ok - finally - biran wang... you get your hacky bmp loader.
cool and thanks. :-)
>
>
>
> Author: raster
> Date: 2011-03-10 04:11:42 -0800 (Thu, 10 Mar 2011)
> New Revision: 57668
> Trac: http://trac.enlightenment.org/e/changeset/57668
>
> Modified:
> trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c
>
> Modified: trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c
> ===
> --- trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c 2011-03-10
> 12:04:00 UTC (rev 57667)
> +++ trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c 2011-03-10
> 12:11:42 UTC (rev 57668)
> @@ -161,6 +161,7 @@
> if (!read_int(f, &tmp2)) goto close_file;
> important_colors = tmp2; // number of important colors - 0 if all
> if (image_size == 0) image_size = fsize - offset;
> + if ((comp == 0) && (bit_count == 32)) hasa = 1; // GIMP seems to
> store it this way
> }
> else if (head_size == 108) // Windows 95/NT4 + (v4)
> {
> @@ -435,6 +436,7 @@
> if (!read_int(f, &tmp2)) goto close_file;
> important_colors = tmp2; // number of important colors - 0 if all
> if (image_size == 0) image_size = fsize - offset;
> + if ((comp == 0) && (bit_count == 32)) hasa = 1; // GIMP seems to
> store it this way
> }
> else if (head_size == 108) // Windows 95/NT4 + (v4)
> {
> @@ -949,6 +951,7 @@
> }
> else if (bit_count == 32)
> {
> + int none_zero_alpha = 0;
> pix = surface;
> for (y = 0; y < h; y++)
> {
> @@ -959,6 +962,7 @@
> g = p[1];
> r = p[2];
> a = p[3];
> + if (a) none_zero_alpha = 1;
> if (!hasa) a = 0xff;
> *pix = ARGB_JOIN(a, r, g, b);
> p += 4;
> @@ -969,6 +973,17 @@
> if (fix > 0) p += 4 - fix; // align row read
> if (p >= buffer_end) break;
> }
> + if (!none_zero_alpha)
> + {
> + ie->flags.alpha = 0;
> + if (hasa)
> + {
> + unsigned int *pixend = pix + (w * h);
> +
> + for (pix = surface; pix < pixend; pix++)
> + A_VAL(pix) = 0xff;
> + }
> + }
> }
> else
> goto close_file;
>
>
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
brian
--
Cool-Karaoke - The smallest recording studio, in your palm, open-sourced
http://cool-idea.com.tw/
iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/bmp
On Thu, 10 Mar 2011, Nicolas Aguirre wrote: > 2011/3/10 Vincent Torri : >> >> forget it >> >> vincent >> > > someone could please fix vtorri.c it seems there is a bug in the > automatic changelog mail system? > > Sorry vincent :P i'm too evil to be fixed. Vincent -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/bmp
2011/3/10 Vincent Torri : > > forget it > > vincent > someone could please fix vtorri.c it seems there is a bug in the automatic changelog mail system? Sorry vincent :P -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/bmp
forget it
vincent
On Thu, 10 Mar 2011, Vincent Torri wrote:
>
> no changelog ?
>
> Vincent
>
> On Thu, 10 Mar 2011, Enlightenment SVN wrote:
>
>> Log:
>> ok - finally - biran wang... you get your hacky bmp loader.
>>
>>
>>
>> Author: raster
>> Date: 2011-03-10 04:11:42 -0800 (Thu, 10 Mar 2011)
>> New Revision: 57668
>> Trac: http://trac.enlightenment.org/e/changeset/57668
>>
>> Modified:
>> trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c
>>
>> Modified: trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c
>> ===
>> --- trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c 2011-03-10
>> 12:04:00 UTC (rev 57667)
>> +++ trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c 2011-03-10
>> 12:11:42 UTC (rev 57668)
>> @@ -161,6 +161,7 @@
>> if (!read_int(f, &tmp2)) goto close_file;
>> important_colors = tmp2; // number of important colors - 0 if all
>> if (image_size == 0) image_size = fsize - offset;
>> +if ((comp == 0) && (bit_count == 32)) hasa = 1; // GIMP seems to
>> store it this way
>> }
>>else if (head_size == 108) // Windows 95/NT4 + (v4)
>> {
>> @@ -435,6 +436,7 @@
>> if (!read_int(f, &tmp2)) goto close_file;
>> important_colors = tmp2; // number of important colors - 0 if all
>> if (image_size == 0) image_size = fsize - offset;
>> +if ((comp == 0) && (bit_count == 32)) hasa = 1; // GIMP seems to
>> store it this way
>> }
>>else if (head_size == 108) // Windows 95/NT4 + (v4)
>> {
>> @@ -949,6 +951,7 @@
>>}
>> else if (bit_count == 32)
>>{
>> + int none_zero_alpha = 0;
>> pix = surface;
>> for (y = 0; y < h; y++)
>> {
>> @@ -959,6 +962,7 @@
>> g = p[1];
>> r = p[2];
>> a = p[3];
>> +if (a) none_zero_alpha = 1;
>> if (!hasa) a = 0xff;
>> *pix = ARGB_JOIN(a, r, g, b);
>> p += 4;
>> @@ -969,6 +973,17 @@
>>if (fix > 0) p += 4 - fix; // align row read
>>if (p >= buffer_end) break;
>> }
>> + if (!none_zero_alpha)
>> +{
>> + ie->flags.alpha = 0;
>> + if (hasa)
>> + {
>> +unsigned int *pixend = pix + (w * h);
>> +
>> +for (pix = surface; pix < pixend; pix++)
>> + A_VAL(pix) = 0xff;
>> + }
>> +}
>>}
>> else
>>goto close_file;
>>
>>
>> --
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> ___
>> enlightenment-svn mailing list
>> enlightenment-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>>
>>
>
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/bmp
no changelog ?
Vincent
On Thu, 10 Mar 2011, Enlightenment SVN wrote:
> Log:
> ok - finally - biran wang... you get your hacky bmp loader.
>
>
>
> Author: raster
> Date: 2011-03-10 04:11:42 -0800 (Thu, 10 Mar 2011)
> New Revision: 57668
> Trac: http://trac.enlightenment.org/e/changeset/57668
>
> Modified:
> trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c
>
> Modified: trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c
> ===
> --- trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c 2011-03-10
> 12:04:00 UTC (rev 57667)
> +++ trunk/evas/src/modules/loaders/bmp/evas_image_load_bmp.c 2011-03-10
> 12:11:42 UTC (rev 57668)
> @@ -161,6 +161,7 @@
> if (!read_int(f, &tmp2)) goto close_file;
> important_colors = tmp2; // number of important colors - 0 if all
> if (image_size == 0) image_size = fsize - offset;
> +if ((comp == 0) && (bit_count == 32)) hasa = 1; // GIMP seems to
> store it this way
> }
>else if (head_size == 108) // Windows 95/NT4 + (v4)
> {
> @@ -435,6 +436,7 @@
> if (!read_int(f, &tmp2)) goto close_file;
> important_colors = tmp2; // number of important colors - 0 if all
> if (image_size == 0) image_size = fsize - offset;
> +if ((comp == 0) && (bit_count == 32)) hasa = 1; // GIMP seems to
> store it this way
> }
>else if (head_size == 108) // Windows 95/NT4 + (v4)
> {
> @@ -949,6 +951,7 @@
>}
> else if (bit_count == 32)
>{
> + int none_zero_alpha = 0;
> pix = surface;
> for (y = 0; y < h; y++)
> {
> @@ -959,6 +962,7 @@
> g = p[1];
> r = p[2];
> a = p[3];
> +if (a) none_zero_alpha = 1;
> if (!hasa) a = 0xff;
> *pix = ARGB_JOIN(a, r, g, b);
> p += 4;
> @@ -969,6 +973,17 @@
>if (fix > 0) p += 4 - fix; // align row read
>if (p >= buffer_end) break;
> }
> + if (!none_zero_alpha)
> +{
> + ie->flags.alpha = 0;
> + if (hasa)
> + {
> +unsigned int *pixend = pix + (w * h);
> +
> +for (pix = surface; pix < pixend; pix++)
> + A_VAL(pix) = 0xff;
> + }
> +}
>}
> else
>goto close_file;
>
>
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/engines/common/evas_op_copy
On Thu, 20 Jan 2011 11:24:46 +0100 (CET) Vincent Torri
said:
>
>
> On Thu, 20 Jan 2011, Enlightenment SVN wrote:
>
> > Log:
> > fix slow path in neon - memcpy is actually faster! :)
>
> maybe we hould add a benchmark soewhere to test memcpy / memset asm
> implementations, for different arch.
>
> Vincent
well expedite tests those as part of just existing - but it wont go testing
every routine explicitly - it uses the one evas picks. this is simply an
optimisation issue and needs what all optimisation things need - profiling and
reading of code and changing it until its actually faster (of course this
varies from arch to arch).
> >
> >
> >
> > Author: raster
> > Date: 2011-01-20 01:33:07 -0800 (Thu, 20 Jan 2011)
> > New Revision: 56240
> > Trac: http://trac.enlightenment.org/e/changeset/56240
> >
> > Modified:
> > trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
> >
> > Modified:
> > trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
> > ===
> > ---
> > trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
> > 2011-01-20 09:27:19 UTC (rev 56239) +++
> > trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
> > 2011-01-20 09:33:07 UTC (rev 56240) @@ -3,61 +3,47 @@
> > #ifdef BUILD_NEON
> > static void
> > _op_copy_p_dp_neon(DATA32 *s, DATA8 *m __UNUSED__, DATA32 c __UNUSED__,
> > DATA32 *d, int l) {
> > - uint32_t *e;
> > - e = d + l;
> > -//#ifdef NEON_INSTRINSICS_OK
> > -#if 0
> > - // odd this is faster than the below asm... :(
> > - e -= 15;
> > - uint32x4_t col1, col2, col3, col4;
> > - // fill a run of 4x4 (16) pixels with the color
> > - for (; d < e; d += 16, s += 16) {
> > - col1 = vld1q_u32(s+0); // OP
> > - col2 = vld1q_u32(s+4); // OP
> > - col3 = vld1q_u32(s+8); // OP
> > - col4 = vld1q_u32(s+12); // OP
> > - vst1q_u32(d+0, col1); // OP
> > - vst1q_u32(d+4, col2); // OP
> > - vst1q_u32(d+8, col3); // OP
> > - vst1q_u32(d+12, col4); // OP
> > - }
> > - e += 15;
> > -#else
> > - if ((e - d) >= 16)
> > + DATA32 *e;
> > +// if (((unsigned long)s & 0xf) || ((unsigned long)d & 0xf))
> > +// {
> > +memcpy(d, s, l * sizeof(DATA32));
> > +//return;
> > +// }
> > +/*
> > + e = d + l - 23;
> > + if (e > d)
> > {
> > -DATA32 *d2, *d3, *d4;
> > -DATA32 *s2, *s3, *s4;
> > -e -= 31;
> > -d2 = d + 4;
> > -d3 = d + 8;
> > -d4 = d + 12;
> > -s2 = s + 4;
> > -s3 = s + 8;
> > -s4 = s + 12;
> > +int dl;
> > asm volatile (
> > - ".fpu neon \n\t"
> > - "asmloop2:\n\t"
> > - "cmp %[e], %[d]\n\t"
> > - "vld1.32 {d16-d17}, [%[s]]!\n\t"
> > - "vld1.32 {d18-d19}, [%[s2]]!\n\t"
> > - "vld1.32 {d20-d21}, [%[s3]]!\n\t"
> > - "vld1.32 {d22-d23}, [%[s4]]!\n\t"
> > - "vst1.32 {d16-d17}, [%[d]]!\n\t"
> > - "vst1.32 {d18-d19}, [%[d2]]!\n\t"
> > - "vst1.32 {d20-d21}, [%[d3]]!\n\t"
> > - "vst1.32 {d22-d23}, [%[d4]]!\n\t"
> > - "bhi asmloop2\n\t"
> > + ".fpu neon \n\t"
> > + "asmloop2: \n\t"
> > + "cmp %[e], %[d] \n\t" // compare current
> > and end ptr
> > + "pld [%[s], #64]\n\t" // preload 64
> > bytes ahead
> > + "pld [%[s], #256] \n\t" // preload 256
> > bytes ahead
> > + "pld [%[s], #320] \n\t" // preload 320
> > bytes ahead
> > + "vld1.64 {d0-d3}, [%[s]]! \n\t" // load 256bits
> > (32 bytes 8 pix)
> > + "vld1.64 {d4-d7} , [%[s]]! \n\t" // load 256bits
> > (32 bytes 8 pix)
> > + "vld1.64 {d8-d11}, [%[s]]! \n\t" // load 256bits
> > (32 bytes 8 pix)
> > + "vst1.64 {d0-d3}, [%[d]]! \n\t" // store 256bits
> > (32 bytes 8 pix)
> > + "vst1.64 {d4-d7}, [%[d]]! \n\t" // store 256bits
> > (32 bytes 8 pix)
> > + "vst1.64 {d8-d11}, [%[d]]! \n\t" // store 256bits
> > (32 bytes 8 pix)
> > + "bhi asmloop2 \n\t"
> > : // output regs
> > - : [s] "r" (s), [s2] "r" (s2), [s3] "r" (s3), [s4]
> > "r" (s4), [e] "r" (e), [d] "r" (d), [d2] "r" (d2), [d3] "r" (d3), [d4]
> > "r" (d4) // input
> > - : "q8", "q9", "q10", "q11", "d16", "d17", "d18",
> > "d19", "d20", "d21", "d22", "d23", "memory" // clobbered
> > - );
> > -e += 31;
> > + : [s] "r" (s), [e] "r" (e), [d] "r" (
Re: [E-devel] E SVN: raster trunk/evas/src/lib/engines/common/evas_op_copy
On Thu, 20 Jan 2011, Enlightenment SVN wrote:
> Log:
> fix slow path in neon - memcpy is actually faster! :)
maybe we hould add a benchmark soewhere to test memcpy / memset asm
implementations, for different arch.
Vincent
>
>
>
> Author: raster
> Date: 2011-01-20 01:33:07 -0800 (Thu, 20 Jan 2011)
> New Revision: 56240
> Trac: http://trac.enlightenment.org/e/changeset/56240
>
> Modified:
> trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
>
> Modified: trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
> ===
> --- trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
> 2011-01-20 09:27:19 UTC (rev 56239)
> +++ trunk/evas/src/lib/engines/common/evas_op_copy/op_copy_pixel_neon.c
> 2011-01-20 09:33:07 UTC (rev 56240)
> @@ -3,61 +3,47 @@
> #ifdef BUILD_NEON
> static void
> _op_copy_p_dp_neon(DATA32 *s, DATA8 *m __UNUSED__, DATA32 c __UNUSED__,
> DATA32 *d, int l) {
> - uint32_t *e;
> - e = d + l;
> -//#ifdef NEON_INSTRINSICS_OK
> -#if 0
> - // odd this is faster than the below asm... :(
> - e -= 15;
> - uint32x4_t col1, col2, col3, col4;
> - // fill a run of 4x4 (16) pixels with the color
> - for (; d < e; d += 16, s += 16) {
> - col1 = vld1q_u32(s+0); // OP
> - col2 = vld1q_u32(s+4); // OP
> - col3 = vld1q_u32(s+8); // OP
> - col4 = vld1q_u32(s+12); // OP
> - vst1q_u32(d+0, col1); // OP
> - vst1q_u32(d+4, col2); // OP
> - vst1q_u32(d+8, col3); // OP
> - vst1q_u32(d+12, col4); // OP
> - }
> - e += 15;
> -#else
> - if ((e - d) >= 16)
> + DATA32 *e;
> +// if (((unsigned long)s & 0xf) || ((unsigned long)d & 0xf))
> +// {
> +memcpy(d, s, l * sizeof(DATA32));
> +//return;
> +// }
> +/*
> + e = d + l - 23;
> + if (e > d)
> {
> -DATA32 *d2, *d3, *d4;
> -DATA32 *s2, *s3, *s4;
> -e -= 31;
> -d2 = d + 4;
> -d3 = d + 8;
> -d4 = d + 12;
> -s2 = s + 4;
> -s3 = s + 8;
> -s4 = s + 12;
> +int dl;
> asm volatile (
> - ".fpu neon \n\t"
> - "asmloop2:\n\t"
> - "cmp %[e], %[d]\n\t"
> - "vld1.32 {d16-d17}, [%[s]]!\n\t"
> - "vld1.32 {d18-d19}, [%[s2]]!\n\t"
> - "vld1.32 {d20-d21}, [%[s3]]!\n\t"
> - "vld1.32 {d22-d23}, [%[s4]]!\n\t"
> - "vst1.32 {d16-d17}, [%[d]]!\n\t"
> - "vst1.32 {d18-d19}, [%[d2]]!\n\t"
> - "vst1.32 {d20-d21}, [%[d3]]!\n\t"
> - "vst1.32 {d22-d23}, [%[d4]]!\n\t"
> - "bhi asmloop2\n\t"
> + ".fpu neon \n\t"
> + "asmloop2: \n\t"
> + "cmp %[e], %[d] \n\t" // compare current
> and end ptr
> + "pld [%[s], #64]\n\t" // preload 64 bytes
> ahead
> + "pld [%[s], #256] \n\t" // preload 256 bytes
> ahead
> + "pld [%[s], #320] \n\t" // preload 320 bytes
> ahead
> + "vld1.64 {d0-d3}, [%[s]]! \n\t" // load 256bits (32
> bytes 8 pix)
> + "vld1.64 {d4-d7} , [%[s]]! \n\t" // load 256bits (32
> bytes 8 pix)
> + "vld1.64 {d8-d11}, [%[s]]! \n\t" // load 256bits (32
> bytes 8 pix)
> + "vst1.64 {d0-d3}, [%[d]]! \n\t" // store 256bits (32
> bytes 8 pix)
> + "vst1.64 {d4-d7}, [%[d]]! \n\t" // store 256bits (32
> bytes 8 pix)
> + "vst1.64 {d8-d11}, [%[d]]! \n\t" // store 256bits (32
> bytes 8 pix)
> + "bhi asmloop2 \n\t"
> : // output regs
> - : [s] "r" (s), [s2] "r" (s2), [s3] "r" (s3), [s4] "r"
> (s4), [e] "r" (e), [d] "r" (d), [d2] "r" (d2), [d3] "r" (d3), [d4] "r" (d4)
> // input
> - : "q8", "q9", "q10", "q11", "d16", "d17", "d18",
> "d19", "d20", "d21", "d22", "d23", "memory" // clobbered
> - );
> -e += 31;
> + : [s] "r" (s), [e] "r" (e), [d] "r" (d) // input
> + : "q0", "q1", "q2", "q3", "q4", "q5",
> + "d0", "d1", "d2", "d3", "d4", "d5",
> + "d6", "d7", "d8", "d9", "d10", "d11",
> + "memory" // clobbered
> + );
> +e = d + l;
> +dl = l - (l % 24);
> +s = s + dl;
> +d = d + dl;
> }
> -#endif
> - // fixup any leftover pixels in the run
>for (; d < e; d++, s++) {
> - *d = *s; // OP
> + *d = *s;
>}
> + */
> }
>
> #define _op_copy_pan_dp_neon _op_copy_p_dp_neon
>
>
>
Re: [E-devel] E SVN: raster trunk/evas/m4
On Wed, 27 Oct 2010 07:33:48 +0200 (CEST) Vincent Torri said: > > > On Wed, 27 Oct 2010, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 27 Oct 2010 07:10:43 +0200 (CEST) Vincent Torri > > said: > >>> -AC_CHECK_HEADERS([X11/X.h X11/extensions/Xrender.h], > >>> +AC_CHECK_HEADERS([X11/Xlib.h X11/extensions/Xrender.h], > >>>[have_dep="yes"], > >>> - [have_dep="no"]) > >>> + [have_dep="no"; break;]) > >> > >> why do you add those break ? > >> > >> Vincent > > > > http://www.gnu.org/software/hello/manual/autoconf/Generic-Headers.html > > > > "For each given system header file header-file in the blank-separated > > argument list that exists, define HAVE_header-file (in all capitals). If > > action-if-found is given, it is additional shell code to execute when one > > of the header files is found. You can give it a value of ÿÿbreakÿÿ to break > > out of the loop on the first match. If action-if-not-found is given, it is > > executed when one of the header files is not found." > > > > according to that the "action if found" is executed when when ONE is found > > (enables), and not found is executed when one is NOT found. as such if last > > header in the list is found and others not found... then we will get an > > erroneous "action if found" conclusion. break on first failure of header > > find stops the loop (even suggested in docs for the true case - also would > > be valid for the not found case). at least thats what the docs say/imply. > > but 'break' seems to be used only in the 'action if found', not in the > 'action if not found' part yes - BUT its symmetrical. it executes that action per header if found or not found - if it works in found, it works in not-found. its a loop as described in the docs. the break stops the loop and gets out. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/m4
On Wed, 27 Oct 2010 07:33:48 +0200 (CEST) Vincent Torri said: > > > On Wed, 27 Oct 2010, Carsten Haitzler (The Rasterman) wrote: > > > On Wed, 27 Oct 2010 07:10:43 +0200 (CEST) Vincent Torri > > said: > >>> -AC_CHECK_HEADERS([X11/X.h X11/extensions/Xrender.h], > >>> +AC_CHECK_HEADERS([X11/Xlib.h X11/extensions/Xrender.h], > >>>[have_dep="yes"], > >>> - [have_dep="no"]) > >>> + [have_dep="no"; break;]) > >> > >> why do you add those break ? > >> > >> Vincent > > > > http://www.gnu.org/software/hello/manual/autoconf/Generic-Headers.html > > > > "For each given system header file header-file in the blank-separated > > argument list that exists, define HAVE_header-file (in all capitals). If > > action-if-found is given, it is additional shell code to execute when one > > of the header files is found. You can give it a value of ÿÿbreakÿÿ to break > > out of the loop on the first match. If action-if-not-found is given, it is > > executed when one of the header files is not found." > > > > according to that the "action if found" is executed when when ONE is found > > (enables), and not found is executed when one is NOT found. as such if last > > header in the list is found and others not found... then we will get an > > erroneous "action if found" conclusion. break on first failure of header > > find stops the loop (even suggested in docs for the true case - also would > > be valid for the not found case). at least thats what the docs say/imply. > > but 'break' seems to be used only in the 'action if found', not in the > 'action if not found' part they are both commands to run in the case of each header being found or not found - according to the docs. break will abort looking for new headers in the list and ensure the final state is one of failure - ie find all headers or fail. the check finds 1 header at a time (it doesnt #include them all together as i found out - thus one of the checks failing). that led me to this little ditty of documentation. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/m4
On Wed, 27 Oct 2010, Carsten Haitzler (The Rasterman) wrote: On Wed, 27 Oct 2010 07:10:43 +0200 (CEST) Vincent Torri said: -AC_CHECK_HEADERS([X11/X.h X11/extensions/Xrender.h], +AC_CHECK_HEADERS([X11/Xlib.h X11/extensions/Xrender.h], [have_dep="yes"], - [have_dep="no"]) + [have_dep="no"; break;]) why do you add those break ? Vincent http://www.gnu.org/software/hello/manual/autoconf/Generic-Headers.html "For each given system header file header-file in the blank-separated argument list that exists, define HAVE_header-file (in all capitals). If action-if-found is given, it is additional shell code to execute when one of the header files is found. You can give it a value of ÿÿbreakÿÿ to break out of the loop on the first match. If action-if-not-found is given, it is executed when one of the header files is not found." according to that the "action if found" is executed when when ONE is found (enables), and not found is executed when one is NOT found. as such if last header in the list is found and others not found... then we will get an erroneous "action if found" conclusion. break on first failure of header find stops the loop (even suggested in docs for the true case - also would be valid for the not found case). at least thats what the docs say/imply. but 'break' seems to be used only in the 'action if found', not in the 'action if not found' part Vincent-- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/m4
On Wed, 27 Oct 2010 07:10:43 +0200 (CEST) Vincent Torri said: > > -AC_CHECK_HEADERS([X11/X.h X11/extensions/Xrender.h], > > +AC_CHECK_HEADERS([X11/Xlib.h X11/extensions/Xrender.h], > >[have_dep="yes"], > > - [have_dep="no"]) > > + [have_dep="no"; break;]) > > why do you add those break ? > > Vincent http://www.gnu.org/software/hello/manual/autoconf/Generic-Headers.html "For each given system header file header-file in the blank-separated argument list that exists, define HAVE_header-file (in all capitals). If action-if-found is given, it is additional shell code to execute when one of the header files is found. You can give it a value of ‘break’ to break out of the loop on the first match. If action-if-not-found is given, it is executed when one of the header files is not found." according to that the "action if found" is executed when when ONE is found (enables), and not found is executed when one is NOT found. as such if last header in the list is found and others not found... then we will get an erroneous "action if found" conclusion. break on first failure of header find stops the loop (even suggested in docs for the true case - also would be valid for the not found case). at least thats what the docs say/imply. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/m4
On Tue, 26 Oct 2010, Enlightenment SVN wrote:
> Log:
> stricter header checking.
>
>
> Author: raster
> Date: 2010-10-26 16:37:28 -0700 (Tue, 26 Oct 2010)
> New Revision: 53906
>
> Modified:
> trunk/evas/m4/evas_check_engine.m4
>
> Modified: trunk/evas/m4/evas_check_engine.m4
> ===
> --- trunk/evas/m4/evas_check_engine.m42010-10-26 23:31:58 UTC (rev
> 53905)
> +++ trunk/evas/m4/evas_check_engine.m42010-10-26 23:37:28 UTC (rev
> 53906)
> @@ -75,9 +75,9 @@
> AC_PATH_X
> AC_PATH_XTRA
>
> -AC_CHECK_HEADERS([X11/X.h X11/extensions/Xrender.h],
> +AC_CHECK_HEADERS([X11/Xlib.h X11/extensions/Xrender.h],
>[have_dep="yes"],
> - [have_dep="no"])
> + [have_dep="no"; break;])
why do you add those break ?
Vincent
>
> if test "x${have_dep}" = "xyes" ; then
>AC_CHECK_LIB([X11], [XCreateImage], [have_dep="yes"], [have_dep="no"])
> @@ -408,7 +408,7 @@
> have_dep="yes"
> evas_engine_[]$1[]_libs="-ld3d9 -ld3dx9 -lgdi32"
>],
> - [have_dep="no"]
> + [have_dep="no"; break]
> )
>
> AC_SUBST([evas_engine_$1_cflags])
> @@ -436,7 +436,7 @@
> AS_IF([test "x${rw_cv_prog_objc_works}" = "xyes"],
> [
>AC_LANG_PUSH([Objective C])
> -
> AC_CHECK_HEADERS([/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h],
> +
> AC_CHECK_HEADER([/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h],
> [
>have_dep="yes"
>evas_engine_[]$1[]_libs="-framework Cocoa"
> @@ -477,7 +477,7 @@
> have_dep="yes"
> evas_engine_[]$1[]_libs="-lglew32 -lopengl32 -lgdi32"
>],
> - [have_dep="no"]
> + [have_dep="no"; break;]
> )
>
> AC_SUBST([evas_engine_$1_cflags])
>
>
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
>
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/cache
On Fri, Sep 25, 2009 at 6:06 AM, Enlightenment SVN wrote: > Log: > i KNOW there is a bug here... the question is.. how to fix it? needs looking into code, but you have 2 options: - do not delete image object if it's in preload queue, instead you flag deleted and on async process function you do the actual cleanup if object was deleted - release references to object. maybe this is not possible due the way async_put is done and we have a pointer to object and not pointer to pointer. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/jpeg
On Mon, 21 Sep 2009 10:09:46 +1000 Carsten Haitzler (The Rasterman) wrote: > On Mon, 21 Sep 2009 02:02:04 +1000 David Seikel > said: > > > On Mon, 21 Sep 2009 01:14:03 +1000 Carsten Haitzler (The Rasterman) > > wrote: > > > > > On Mon, 21 Sep 2009 01:08:06 +1000 David Seikel > > > said: > > > > > > > On Sun, 20 Sep 2009 07:31:48 -0700 "Enlightenment SVN" > > > > wrote: > > > > > > > > > Log: > > > > > handle regions for all jpeg types (cymk, rgb, gray). other > > > > > formats dont support this (atm). there is possibly little > > > > > point in doing so... perhaps svg... thought maybe tiff too > > > > > later? for now, get jpeg 100% up to snuff. > > > > > > > > Which reminds me. What's the status of jpeg 2000 support in > > > > EFL? > > > > > > there is none? have yet to see jpeg2000 in real use (ie there > > > being a need for support). :/ > > > > Second Life (SL) uses it extensively. Unfortunately, one of the > > few non open source parts of SL is the jpeg 2000 library they use. > > There is an alternative open source library you can use, but it's > > slower. I was hoping that we could do a very fast implementation > > that I could hack into SL. But, hacking up SL for other things is > > much higher on my TODO list. So I guess that will remain a pipe > > dream for now. B-( > > there is no way i'd implement a whole jpeg2k decoder lib. i'd simply > use the open source one. it's not anywhere important enough to > warrant that - and well.. second life seems to be an exception - > thats the first i've heard of it being used. Pretty much everything you see in SL is delivered over the 'net via jpeg2000, except text. Guess when it becomes critical for me, I'll just optimise the current open source library. > not that SL would use evas... :) It might when I'm done with it. Muhahahaha. Someone is porting SL to GTK, I see no reason it could not be ported to EFL and friends. I'm already being paid to port some other game over to as much of EFL as is appropriate. signature.asc Description: PGP signature -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/jpeg
On Mon, 21 Sep 2009 02:02:04 +1000 David Seikel said: > On Mon, 21 Sep 2009 01:14:03 +1000 Carsten Haitzler (The Rasterman) > wrote: > > > On Mon, 21 Sep 2009 01:08:06 +1000 David Seikel > > said: > > > > > On Sun, 20 Sep 2009 07:31:48 -0700 "Enlightenment SVN" > > > wrote: > > > > > > > Log: > > > > handle regions for all jpeg types (cymk, rgb, gray). other > > > > formats dont support this (atm). there is possibly little point > > > > in doing so... perhaps svg... thought maybe tiff too later? for > > > > now, get jpeg 100% up to snuff. > > > > > > Which reminds me. What's the status of jpeg 2000 support in EFL? > > > > there is none? have yet to see jpeg2000 in real use (ie there being a > > need for support). :/ > > Second Life (SL) uses it extensively. Unfortunately, one of the few non > open source parts of SL is the jpeg 2000 library they use. There is an > alternative open source library you can use, but it's slower. I was > hoping that we could do a very fast implementation that I could hack > into SL. But, hacking up SL for other things is much higher on my TODO > list. So I guess that will remain a pipe dream for now. B-( there is no way i'd implement a whole jpeg2k decoder lib. i'd simply use the open source one. it's not anywhere important enough to warrant that - and well.. second life seems to be an exception - thats the first i've heard of it being used. not that SL would use evas... :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/jpeg
On Mon, 21 Sep 2009 01:14:03 +1000 Carsten Haitzler (The Rasterman) wrote: > On Mon, 21 Sep 2009 01:08:06 +1000 David Seikel > said: > > > On Sun, 20 Sep 2009 07:31:48 -0700 "Enlightenment SVN" > > wrote: > > > > > Log: > > > handle regions for all jpeg types (cymk, rgb, gray). other > > > formats dont support this (atm). there is possibly little point > > > in doing so... perhaps svg... thought maybe tiff too later? for > > > now, get jpeg 100% up to snuff. > > > > Which reminds me. What's the status of jpeg 2000 support in EFL? > > there is none? have yet to see jpeg2000 in real use (ie there being a > need for support). :/ Second Life (SL) uses it extensively. Unfortunately, one of the few non open source parts of SL is the jpeg 2000 library they use. There is an alternative open source library you can use, but it's slower. I was hoping that we could do a very fast implementation that I could hack into SL. But, hacking up SL for other things is much higher on my TODO list. So I guess that will remain a pipe dream for now. B-( signature.asc Description: PGP signature -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/jpeg
On Mon, 21 Sep 2009 01:08:06 +1000 David Seikel said: > On Sun, 20 Sep 2009 07:31:48 -0700 "Enlightenment SVN" > wrote: > > > Log: > > handle regions for all jpeg types (cymk, rgb, gray). other formats > > dont support this (atm). there is possibly little point in doing > > so... perhaps svg... thought maybe tiff too later? for now, get jpeg > > 100% up to snuff. > > Which reminds me. What's the status of jpeg 2000 support in EFL? there is none? have yet to see jpeg2000 in real use (ie there being a need for support). :/ -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/modules/loaders/jpeg
On Sun, 20 Sep 2009 07:31:48 -0700 "Enlightenment SVN" wrote: > Log: > handle regions for all jpeg types (cymk, rgb, gray). other formats > dont support this (atm). there is possibly little point in doing > so... perhaps svg... thought maybe tiff too later? for now, get jpeg > 100% up to snuff. Which reminds me. What's the status of jpeg 2000 support in EFL? signature.asc Description: PGP signature -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/engines/common
On Mon, Aug 3, 2009 at 5:19 AM, Enlightenment SVN wrote: > Log: > Ticket #372 - patch. fix. i guess this would be true on common16 as I used the same code as base AFAIR -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/file
On Sun, 28 Dec 2008 10:59:21 + Ian Lee
babbled:
aaah more. yeah - didnt see them (they weren't causing me problems at the
time) :) fixed there too.
> > Modified: trunk/evas/src/lib/file/evas_module.c
> > ===
> > --- trunk/evas/src/lib/file/evas_module.c 2008-12-23 23:15:53 UTC
> (rev > 38313)
> > +++ trunk/evas/src/lib/file/evas_module.c 2008-12-23 23:54:51 UTC
> (rev > 38314)
> > @@ -174,7 +174,7 @@
> > em->handle = NULL;
> > em->data = NULL;
> > em->loaded = 0;
> > -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> > +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
> > pthread_spin_init(&em->lock, PTHREAD_PROCESS_PRIVATE);
> > #endif
> > if (em->type == EVAS_MODULE_TYPE_ENGINE)
>
>
> Dont all the #ifdefs need to change, edje_cc hangs otherwise.
> Quick patch below
>
> thanks
> Ian
>
> --- /home/ian/Desktop/evas_module.c 2008-12-28 10:47:43.455093172 +
> +++ evas_module.c 2008-12-28 10:41:46.288093315 +
> @@ -309,7 +309,7 @@
> em->func.close = NULL;
> em->api = NULL;
> em->loaded = 0;
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
> pthread_spin_destroy(&em->lock);
> #endif
> }
> @@ -317,12 +317,12 @@
> void
> evas_module_ref(Evas_Module *em)
> {
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
> pthread_spin_lock(&em->lock);
> #endif
> em->ref++;
> /* printf("M: %s ref++ = %i\n", em->name, em->ref); */
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
> pthread_spin_unlock(&em->lock);
> #endif
> }
> @@ -330,12 +330,12 @@
> void
> evas_module_unref(Evas_Module *em)
> {
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
> pthread_spin_lock(&em->lock);
> #endif
> em->ref--;
> /* printf("M: %s ref-- = %i\n", em->name, em->ref); */
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
> pthread_spin_unlock(&em->lock);
> #endif
> }
>
>
>
>
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/file
> Modified: trunk/evas/src/lib/file/evas_module.c
> ===
> --- trunk/evas/src/lib/file/evas_module.c 2008-12-23 23:15:53 UTC
(rev > 38313)
> +++ trunk/evas/src/lib/file/evas_module.c 2008-12-23 23:54:51 UTC
(rev > 38314)
> @@ -174,7 +174,7 @@
> em->handle = NULL;
> em->data = NULL;
> em->loaded = 0;
> -#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
> +#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
> pthread_spin_init(&em->lock, PTHREAD_PROCESS_PRIVATE);
> #endif
> if (em->type == EVAS_MODULE_TYPE_ENGINE)
Dont all the #ifdefs need to change, edje_cc hangs otherwise.
Quick patch below
thanks
Ian
--- /home/ian/Desktop/evas_module.c 2008-12-28 10:47:43.455093172 +
+++ evas_module.c 2008-12-28 10:41:46.288093315 +
@@ -309,7 +309,7 @@
em->func.close = NULL;
em->api = NULL;
em->loaded = 0;
-#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
+#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
pthread_spin_destroy(&em->lock);
#endif
}
@@ -317,12 +317,12 @@
void
evas_module_ref(Evas_Module *em)
{
-#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
+#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
pthread_spin_lock(&em->lock);
#endif
em->ref++;
/* printf("M: %s ref++ = %i\n", em->name, em->ref); */
-#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
+#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
pthread_spin_unlock(&em->lock);
#endif
}
@@ -330,12 +330,12 @@
void
evas_module_unref(Evas_Module *em)
{
-#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
+#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
pthread_spin_lock(&em->lock);
#endif
em->ref--;
/* printf("M: %s ref-- = %i\n", em->name, em->ref); */
-#if defined(HAVE_PTHREAD_H) && defined(BUILD_ASYNC_PRELOAD)
+#if defined(BUILD_PTHREAD) && defined(BUILD_ASYNC_PRELOAD)
pthread_spin_unlock(&em->lock);
#endif
}
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
Go Sachiel :)
dh
Enlightenment SVN wrote:
> Log:
> another sachiel fix! :)
>
>
> Author: raster
> Date: 2008-10-28 20:29:10 -0700 (Tue, 28 Oct 2008)
> New Revision: 37292
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_textblock.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_textblock.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-10-29 01:51:45 UTC
> (rev 37291)
> +++ trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-10-29 03:29:10 UTC
> (rev 37292)
> @@ -1788,12 +1788,16 @@
>
> if ((repch) && (n->text))
> {
> - int i, len = strlen(n->text), chlen;
> + int i = 0, len = 0, chlen;
> + char *ptr;
>
> + while (evas_common_font_utf8_get_next(n->text, &i))
> + len++;
> chlen = strlen(repch);
> str = alloca((len * chlen) + 1);
> - for (i = 0; i < len; i += chlen)
> - strcpy(&(str[i]), repch);
> + for (i = 0, ptr = str; i < len; ptr += chlen, i++)
> + memcpy(ptr, repch, chlen);
> + *ptr = 0;
> }
> else
> str = n->text;
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-svn mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
I would Agreetho are those in the past that say we have done just
that.
Isn't that what we do...duplicate code ? :P.well after a while
doesn't that code become better??
Long Live E
dh (cpm)
Enlightenment SVN wrote:
> Log:
> dont repeat code
>
>
> Author: raster
> Date: 2008-10-26 20:12:59 -0700 (Sun, 26 Oct 2008)
> New Revision: 37191
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_textblock.c
>
> Modified: trunk/evas/src/lib/canvas/evas_object_textblock.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-10-27 03:03:59 UTC
> (rev 37190)
> +++ trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-10-27 03:12:59 UTC
> (rev 37191)
> @@ -2682,22 +2682,11 @@
> _prepend_escaped_char(Evas_Textblock_Cursor *cur, const char *s,
>const char *s_end)
> {
> - const char *map_itr, *map_end;
> -
> - map_itr = escape_strings;
> - map_end = map_itr + sizeof(escape_strings);
> -
> - while (map_itr < map_end)
> - {
> - if (_is_eq_and_advance(s, s_end, &map_itr, map_end))
> - {
> - evas_textblock_cursor_text_prepend(cur, map_itr);
> - return;
> - }
> -
> - if (map_itr < map_end)
> - _advance_after_end_of_string(&map_itr);
> - }
> + const char *escape;
> +
> + escape = _escaped_char_get(s, s_end);
> + if (escape)
> + evas_textblock_cursor_text_prepend(cur, escape);
> }
>
> /**
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-svn mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/evas/src/lib/canvas
fp...better for a scale...more precision
dh
[EMAIL PROTECTED] wrote:
> Author: raster
> Date: 2008-09-09 23:40:54 -0700 (Tue, 09 Sep 2008)
> New Revision: 35924
>
> Modified:
> trunk/evas/src/lib/canvas/evas_object_text.c
> trunk/evas/src/lib/canvas/evas_object_textblock.c
> Log:
>
> ensure scaling multiplies are promoted to fp.
>
>
>
> Modified: trunk/evas/src/lib/canvas/evas_object_text.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_text.c 2008-09-10 06:40:24 UTC
> (rev 35923)
> +++ trunk/evas/src/lib/canvas/evas_object_text.c 2008-09-10 06:40:54 UTC
> (rev 35924)
> @@ -191,7 +191,6 @@
> evas_font_free(obj->layer->evas, o->engine_data);
> o->engine_data = NULL;
> }
> - o->engine_data = evas_font_load(obj->layer->evas, font, o->cur.source,
> (int)(((double)size) * obj->cur.scale));
> if (!same_font)
> {
> if (o->cur.font) evas_stringshare_del(o->cur.font);
> @@ -200,6 +199,8 @@
> o->prev.font = NULL;
> }
> o->cur.size = size;
> + o->engine_data = evas_font_load(obj->layer->evas, o->cur.font,
> o->cur.source,
> +(int)(((double)o->cur.size) *
> obj->cur.scale));
> evas_text_style_pad_get(o->cur.style, &l, &r, &t, &b);
> if ((o->engine_data) && (o->cur.text))
> {
>
> Modified: trunk/evas/src/lib/canvas/evas_object_textblock.c
> ===
> --- trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-09-10 06:40:24 UTC
> (rev 35923)
> +++ trunk/evas/src/lib/canvas/evas_object_textblock.c 2008-09-10 06:40:54 UTC
> (rev 35924)
> @@ -1168,6 +1168,7 @@
> }
> else if (fmt->font.name)
> buf = strdup(fmt->font.name);
> +
> fmt->font.font = evas_font_load(obj->layer->evas,
> buf, fmt->font.source,
> (int)(((double)fmt->font.size) *
> obj->cur.scale));
> @@ -1290,7 +1291,7 @@
> else if (fmt2->font.name)
> buf = strdup(fmt2->font.name);
> fmt2->font.font = evas_font_load(obj->layer->evas,
> -buf, fmt2->font.source,
> + buf, fmt2->font.source,
> (int)(((double)fmt2->font.size) *
> obj->cur.scale));
> if (buf) free(buf);
> return fmt2;
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> enlightenment-svn mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
