Re: [E-devel] Ecore Con : interruption of UI interaction issue.
On Wed, 28 Sep 2011 14:31:12 +0900 Daniel Juyung Seo
said:
h the stuff that happens while you're away. sorry guys - i don't like this.
spinning int he ilder EVEN if you limit it to 0.7* frametime.. is bad. idlers
spin already. they just spin OUTSIDE the idler callback. (i.e. they keep
calling the callback in a loop while the app is idle). sp please - don't do
this kind of thing in idlers if you can avoid it (eg if the cost of going in
and out of the idler is high, then sure, do some spins inside, but in this
case, it isn't)...
/me fixes and makes test cases
> In SVN!
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
> On Tue, Sep 27, 2011 at 4:47 PM, Kim Yunhan wrote:
> > Thanks a lot!
> >
> > On Tue, Sep 27, 2011 at 4:29 PM, Cedric BAIL wrote:
> >
> >> On Tue, Sep 27, 2011 at 8:56 AM, Daniel Juyung Seo
> >> wrote:
> >> > No more comments on this patch?
> >>
> >> It's good could get in today.
> >>
> >> > If so, I'll commit this in a day.
> >>
> >> I was lacking network access. Now I am back, I can commit and break
> >> stuff again ! Yeah !
> >>
> >
> > lol ;-)
> >
> >
> >>
> >> > On Thu, Sep 22, 2011 at 10:22 PM, Kim Yunhan wrote:
> >> >> Of course, the multiplication won't matter at all. :)
> >> >> I couldn't predict how much time will be taken in ecore main loop.
> >> >> There exists similar code in Ecore_Con_Url and if download is stared, it
> >> >> will be called many times.
> >> >> So I guess that it could be affected with download performance. (though
> >> it
> >> >> will be a little)
> >> >> That was my concern.
> >> >> But I thought it again and UI interaction is more important than
> >> download
> >> >> performance.
> >> >> Therefore I'll send a patch again you suggested.
> >> >>
> >> >> Thank you.
> >> >>
> >> >> Index: ecore/src/lib/ecore_con/ecore_con_url.c
> >> >> ===
> >> >> --- ecore/src/lib/ecore_con/ecore_con_url.c (revision 63527)
> >> >> +++ ecore/src/lib/ecore_con/ecore_con_url.c (working copy)
> >> >> @@ -1357,15 +1357,21 @@
> >> >> int fd_max, fd;
> >> >> int flags, still_running;
> >> >> int completed_immediately = 0;
> >> >> + double start;
> >> >> CURLMcode ret;
> >> >>
> >> >> _url_con_list = eina_list_append(_url_con_list, url_con);
> >> >>
> >> >> url_con->active = EINA_TRUE;
> >> >> curl_multi_add_handle(_curlm, url_con->curl_easy);
> >> >> - /* This one can't be stopped, or the download never start. */
> >> >> - while (curl_multi_perform(_curlm, &still_running) ==
> >> >> CURLM_CALL_MULTI_PERFORM) ;
> >> >>
> >> >> + start = ecore_time_get();
> >> >> + while (curl_multi_perform(_curlm, &still_running) ==
> >> >> CURLM_CALL_MULTI_PERFORM)
> >> >> + if ((ecore_time_get() - start) > (0.7 *
> >> >> ecore_animator_frametime_get()))
> >> >> + {
> >> >> + break;
> >> >> + }
> >> >> +
> >> >> completed_immediately =
> >> _ecore_con_url_process_completed_jobs(url_con);
> >> >>
> >> >> if (!completed_immediately)
> >> >> @@ -1456,7 +1462,7 @@
> >> >> start = ecore_time_get();
> >> >> while (curl_multi_perform(_curlm, &still_running) ==
> >> >> CURLM_CALL_MULTI_PERFORM)
> >> >> /* make this not more than a frametime to keep interactivity high
> >> */
> >> >> - if ((ecore_time_get() - start) > ecore_animator_frametime_get())
> >> >> + if ((ecore_time_get() - start) > (0.7 *
> >> >> ecore_animator_frametime_get()))
> >> >> {
> >> >> done = 0;
> >> >> break;
> >> >>
> >> >>
> >> >> On Thu, Sep 22, 2011 at 9:33 PM, Gustavo Sverzut Barbieri <
> >> >> barbi...@profusion.mobi> wrote:
> >> >>
> >> >>> What will change? The multiplication won't matter and you can move it
> >> >>> outside of the loop. If there is nothing else to be done in the
> >> mainloop it
> >> >>> will do few function calls and get back to work.
> >> >>>
> >> >>> If you allow the full frametime to be used, whenever the user will try
> >> to
> >> >>> do
> >> >>> work the frametime will be gone and skips will happen, even under low
> >> load!
> >> >>>
> >> >>> If someone is considering download speed I strongly recommend doing
> >> >>> splice()
> >> >>> to avoid it coming from kernel to userspace then back to kernel
> >> >>>
> >> >>> Things like servers using ecore don't need frametime at all, thus they
> >> can
> >> >>> make it a few seconds or minutes :-)
> >> >>>
> >> >>> On Thursday, September 22, 2011, Kim Yunhan wrote:
> >> >>> > It sounds good. But I'm wonder download performance will be impaired.
> >> >>> :'-(
> >> >>> > It should be tested much more.
> >> >>> >
> >> >>> > On Thu, Sep 22, 2011 at 8:13 PM, Gustavo Sverzut Barbieri <
> >> >>> > barbi...@profusion.mobi> wrote:
> >> >>> >
> >> >>> >> Better to use a percentual if frametime otherwise user will try to
> >> do
> >> >>> some
> >> >>> >> work and it will not have enough time. Something like 0.7 *
> >> >>> >> ecore_animator_frametime_get()
> >> >>> >>
> >> >>> >> On Thursday, September 22
Re: [E-devel] [Patch] elm_diskselector, set icon to added item
On Thu, 22 Sep 2011 18:39:53 +0900 cnook said: > Dear All, Hello! > > If the diskselector is round mode, the scroller of diskselector has > additional items for its rounding(carousel) effect. > Previously, elm_diskselector_item_icon_set(); did not care about > theses additional items. > Please review the attached patch that will care. Thanks. hmm ok - in svn. not giving this a lot of review. i was reviewing diskselector about a week ago or so and realized.. this widget needs a major overhaul in internal design and implementation. to implement a rounded disk - it really needs to use map, and even then the amount of rounding or if any at all should be configurable. it should almost definitely implement this with a pan smart like genlist does to allow for a virtual pan area (we can make it almost infinite - well make it just very very very very large) and based on position int he virtual pan, position children (really just use a box with map used to duplicate it on the curved or visibile area). -- - 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-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] add edje_object_all_parts_default_state_set API
On Fri, 23 Sep 2011 17:42:15 +0900 Daniel Juyung Seo said: yup. you really want a "reset to state just after load" ... ie reset.. not just the part states. everything (embryo vm's, lua etc.) > Good observation. Thanks a lot. This is what we really need :) > > Daniel Juyung Seo (SeoZ) > > On Fri, Sep 23, 2011 at 5:29 PM, Cedric BAIL wrote: > > 2011/9/23 Jaehwan Kim : > >> Dear all, > >> > >> I made a API "edje_object_all_parts_default_state_set(Evas_Object obj)" > >> This work was requested by Daniel Juyung Seo. > >> This API sets the state of all parts to default. > >> Please check attached patch file. > > > > The patch is simple to understand, so far so good. First remark, you > > should better call _edje_recalc(ed); instead of edje_object_calc_force > > as their is no need yet to recalculate everything it can wait. > > > > The second and most concerning issue to me, is that you are changing > > part state without resetting the embryo or lua vm and other internal > > program. I think it is necessary, because you don't know what is > > currently running inside it. So I would prefer this patch to implement > > just a edje_object_reset(Evas_Object obj) that will also reset the > > various vm, destroy all pending timer, destroy the content of the > > event queue and stop all pending program. With that function we could > > easily reuse the Edje object from a cache without the need to add a > > special state that would reset it to default. > > -- > > Cedric BAIL > > > > -- > > All of the data generated in your IT infrastructure is seriously valuable. > > Why? It contains a definitive record of application performance, security > > threats, fraudulent activity, and more. Splunk takes this data and makes > > sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-d2dcopy2 > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > ___ > 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-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [E-debel][Patch] Changing format of egl_Image to BGRA
Dear All, When egl_image is created, texture format is set to RGBA. But, egl_image will be created with BGRA format. So, below works are needed. 1. Define new enum "EGL_MAP_GL_TEXTURE_BGRA_SEC" 2. Set attribute to "EGL_MAP_GL_TEXTURE_BGRA_SEC" 3. Change shader program from img_nomul to img_bgra_nomul Please find a enclosed patch file. Thanks. evas_gl_BGRA_modification.diff Description: Binary data -- 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-d2dcopy1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [E-debel][Patch] Changing format of egl_Image to BGRA
On Mon, 10 Oct 2011 10:12:13 + (GMT) 우승수 said: > Dear All, > > When egl_image is created, texture format is set to RGBA. > But, egl_image will be created with BGRA format. > > So, below works are needed. > 1. Define new enum "EGL_MAP_GL_TEXTURE_BGRA_SEC" > 2. Set attribute to "EGL_MAP_GL_TEXTURE_BGRA_SEC" > 3. Change shader program from img_nomul to img_bgra_nomul > > Please find a enclosed patch file. actually already applied this.. with a fix. it missed 1 more case with evas_gl_common_shader_choice(). you changed the image draw routine and not the map draw routine as well. :) -- - 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-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_diskselector, set icon to added item
Wow this sounds like diskselector needs to be rewritten a lot. Daniel Juyung Seo (SeoZ) On Mon, Oct 10, 2011 at 6:45 PM, Carsten Haitzler wrote: > On Thu, 22 Sep 2011 18:39:53 +0900 cnook said: > >> Dear All, Hello! >> >> If the diskselector is round mode, the scroller of diskselector has >> additional items for its rounding(carousel) effect. >> Previously, elm_diskselector_item_icon_set(); did not care about >> theses additional items. >> Please review the attached patch that will care. Thanks. > > hmm ok - in svn. not giving this a lot of review. i was reviewing diskselector > about a week ago or so and realized.. this widget needs a major overhaul in > internal design and implementation. to implement a rounded disk - it really > needs to use map, and even then the amount of rounding or if any at all should > be configurable. it should almost definitely implement this with a pan smart > like genlist does to allow for a virtual pan area (we can make it almost > infinite - well make it just very very very very large) and based on position > int he virtual pan, position children (really just use a box with map used to > duplicate it on the curved or visibile area). > > -- > - 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-d2dcopy1 > ___ > 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-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elm_diskselector, set icon to added item
On Mon, 10 Oct 2011 22:45:56 +0900 Daniel Juyung Seo said: at least it can retain its api. :) > Wow this sounds like diskselector needs to be rewritten a lot. > > Daniel Juyung Seo (SeoZ) > > On Mon, Oct 10, 2011 at 6:45 PM, Carsten Haitzler > wrote: > > On Thu, 22 Sep 2011 18:39:53 +0900 cnook said: > > > >> Dear All, Hello! > >> > >> If the diskselector is round mode, the scroller of diskselector has > >> additional items for its rounding(carousel) effect. > >> Previously, elm_diskselector_item_icon_set(); did not care about > >> theses additional items. > >> Please review the attached patch that will care. Thanks. > > > > hmm ok - in svn. not giving this a lot of review. i was reviewing > > diskselector about a week ago or so and realized.. this widget needs a > > major overhaul in internal design and implementation. to implement a > > rounded disk - it really needs to use map, and even then the amount of > > rounding or if any at all should be configurable. it should almost > > definitely implement this with a pan smart like genlist does to allow for a > > virtual pan area (we can make it almost infinite - well make it just very > > very very very large) and based on position int he virtual pan, position > > children (really just use a box with map used to duplicate it on the curved > > or visibile area). > > > > -- > > - 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-d2dcopy1 > > ___ > > 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-d2dcopy1 > ___ > 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-d2dcopy1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Elm entry sizing issue
On Fri, Oct 7, 2011 at 7:45 PM, Carsten Haitzler wrote:
> On Fri, 7 Oct 2011 14:16:58 -0700 "Ausmus, James"
> said:
>
>> On Fri, Oct 7, 2011 at 2:20 AM, Tom Hacohen wrote:
>> > I'm away from home/computers until Saturday evening (leaving now), I'll
>> > take a look at it soon after.
>> >
>> > But I have a couple of questions until then:
>> > What sizing do you get? what do you expect? The elm minimum height
>> > should change according to the font size (unless it's smaller than the
>> > finger size, which is then used).
>>
>> It's taller than the part underneath it that it is set to be relative
>> to and smaller than. However, I'm betting that the finger size thing
>> is the issue here - any way to override/set the finger size
>> dynamically, to be able to get around that limitation in one-off
>> situations?
>
> use a label then, not entry. an entry is there for the purpose of entering
> text or selecting it etc. - not just display. thus it forces it to be at least
> a finger size in height for single line entries (for multiple line its a bit
> nastier so it doesn't currently). the whole point of finger size it to ensure
> a
> person can reliably press on it. if you have a desktop app finger size should
> be globally on your system set to something low - like "5". so you wont have a
> problem. but elm is fixing the ui to make it usable for people. you don't need
> your ui test department now to tell you to fix it anymore. :)
Unfortunately, I need actual text entry, not just display. I agree
that, if *everything* else on a given platform is working correctly,
then the finger size should already be set at the appropriate value,
and everything would work great. However, if there are other
platform-level issues/misconfigurations/evolutions in play, I either
have to wait for someone else to finish their job, do someone else's
job for them, or just have my deliverables look ugly (and most
higher-level managers I've dealt with don't usually like the "It's not
my fault/job!" answer...).
Again, I agree with the concept, but not having any way to work around
it, *forcing* every possible application to fit within a pre-conceived
paradigm of how the platform should work, seems a little
over-restrictive and broken...
Thanks!
-James
>
>> Thanks!
>>
>> -James
>>
>> >
>> > --
>> > Tom.
>> >
>> > On 07/10/11 02:45, Ausmus, James wrote:
>> >> Hi All-
>> >>
>> >> It appears that a standard Elementary entry widget has a minimum
>> >> height that it refuses to size beneath, regardless of the font size
>> >> being used, as demonstrated by the entry.c and entry.edc files below.
>> >>
>> >> Is there any way around this? How can I get a "short" Elm entry that
>> >> actually obeys the size of the swallow - do I need to fully grok and
>> >> recreate the default Elm theme for an entry in order to reduce the min
>> >> height of it's visual components, or is there a (much) easier way? :)
>> >>
>> >> Thanks!
>> >>
>> >> -James
>> >>
>> >>
>> >> //
>> >> /*Begin entry.c */
>> >> #include
>> >> #include
>> >> #include
>> >>
>> >> //UI signal callbacks
>> >>
>> >> static Evas_Object *ly;
>> >>
>> >> void main_quit_cb(void *data, Evas_Object *obj,
>> >> const char *emission, const char *source)
>> >> {
>> >> int x, y, h, w;
>> >> edje_object_part_geometry_get(elm_layout_edje_get(ly),
>> >> "input_bg", &x, &y, &w, &h);
>> >> printf("after ibg geo: %i/%i, %i/%i\n", x, y, w, h);
>> >> edje_object_part_geometry_get(elm_layout_edje_get(ly),
>> >> "input_swallow", &x, &y, &w, &h);
>> >> printf("after is geo: %i/%i, %i/%i\n", x, y, w, h);
>> >> elm_exit();
>> >> }
>> >>
>> >> static Evas_Object* load_edj(Evas_Object *parent, const char *file,
>> >> const char *group)
>> >> {
>> >> Evas_Object *eo;
>> >> int r;
>> >>
>> >> eo = elm_layout_add(parent);
>> >> if (eo) {
>> >> r = elm_layout_file_set(eo, file, group);
>> >> if (!r) {
>> >> evas_object_del(eo);
>> >> return NULL;
>> >> }
>> >>
>> >> evas_object_size_hint_weight_set(eo,
>> >> EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
>> >> }
>> >> return eo;
>> >> }
>> >>
>> >> int elm_main(int argc, char *argv[])
>> >> {
>> >> Evas_Object *win = NULL;
>> >> Evas_Object *tb;
>> >> int nw, nh;
>> >>
>> >> /* create window */
>> >> win = elm_win_add(NULL, "entry", ELM_WIN_BASIC);
>> >> if (win) {
>> >> elm_win_title_set(win, "entry");
>> >> ecore_x_window_size_get(ecore_x_window_root_first_get(),
>> >> &nw, &nh);
>> >> evas_object_resize(win, nw, nh);
>> >> } else {
>> >> printf("couldn't cr
Re: [E-devel] Evas GL engine shader issue
On Sat, Oct 08, 2011 at 11:56:05AM +0900, Carsten Haitzler wrote:
> On Fri, 7 Oct 2011 13:40:35 -0700 Jim Kukunas
>
> said:
>
> evas does have code to get the actual compile error in gl_compile_link_error()
> - but your mail doesn't paste any of that. it should be right above what you
> pasted if the glsl compiler is reporting errors in error logs. (it also would
> have complained about fragment compile error too before that).
Hmm, so I see. I must have missed it. One of the downsides to a small netbook
screen...
Anyway after your fix, it works fine again.
Thanks.
>
> > Hi Folks,
> >
> > With Evas trunk, I can no longer use the gl_x11 engine on my Intel 945GME.
> > I get the error message reproduced below.
> >
> > Git bisect points to revision 63832. Any revision before that works fine.
> >
> > Anyone else having this issue? I can supply more info if needed.
> >
> > Thanks.
> >
> > ERR<1246>:evas-gl_common evas_gl_shader.c:1082
> > _evas_gl_common_shader_program_source_init() Abort compile of shader vert
> > (nv12): #ifdef GL_ES
> > #ifdef GL_FRAGMENT_PRECISION_HIGH
> > precision highp float;
> > #else
> > precision mediump float;
> > #endif
> > #endif
> > attribute vec4 vertex;
> > attribute vec4 color;
> > attribute vec2 tex_coord, tex_coord2;
> > uniform mat4 mvp;
> > varying vec4 col;
> > varying vec2 tex_y, tex_cuv;
> > void main()
> > {
> >gl_Position = mvp * vertex;
> >col = color;
> >tex_y = tex_coord;
> >tex_cuv = tex_coord2 * 0.5;
> > }
> >
> > Evas can not setup the informations of the OpenGL X11 Engine
> > No engine selected.
> >
> > --
> > Jim Kukunas
> > Intel Open Source Technology Center
> >
> > --
> > All of the data generated in your IT infrastructure is seriously valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy2
> > ___
> > 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
--
Jim Kukunas
Intel Open Source Technology Center
--
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-d2dcopy1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fruitbar for engage
On Mon, Oct 10, 2011 at 9:25 PM, Leif Middelschulte wrote: > Hello all, > > find attached an initial patch for engage, that provides features for > engage, much like those of a famous fruit company. > Fruitbar is just a working title. It shall become a proper name soon. > cannot test. ng_fruitbar.h is missing BR > -- > Leif > > -- > 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-d2dcopy1 > ___ > 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] Elm entry sizing issue
On Mon, 10 Oct 2011 09:57:33 -0700 "Ausmus, James" said: > On Fri, Oct 7, 2011 at 7:45 PM, Carsten Haitzler wrote: > > On Fri, 7 Oct 2011 14:16:58 -0700 "Ausmus, James" > > said: > > > >> On Fri, Oct 7, 2011 at 2:20 AM, Tom Hacohen wrote: > >> > I'm away from home/computers until Saturday evening (leaving now), I'll > >> > take a look at it soon after. > >> > > >> > But I have a couple of questions until then: > >> > What sizing do you get? what do you expect? The elm minimum height > >> > should change according to the font size (unless it's smaller than the > >> > finger size, which is then used). > >> > >> It's taller than the part underneath it that it is set to be relative > >> to and smaller than. However, I'm betting that the finger size thing > >> is the issue here - any way to override/set the finger size > >> dynamically, to be able to get around that limitation in one-off > >> situations? > > > > use a label then, not entry. an entry is there for the purpose of entering > > text or selecting it etc. - not just display. thus it forces it to be at > > least a finger size in height for single line entries (for multiple line > > its a bit nastier so it doesn't currently). the whole point of finger size > > it to ensure a person can reliably press on it. if you have a desktop app > > finger size should be globally on your system set to something low - like > > "5". so you wont have a problem. but elm is fixing the ui to make it usable > > for people. you don't need your ui test department now to tell you to fix > > it anymore. :) > > > Unfortunately, I need actual text entry, not just display. I agree > that, if *everything* else on a given platform is working correctly, > then the finger size should already be set at the appropriate value, > and everything would work great. However, if there are other > platform-level issues/misconfigurations/evolutions in play, I either > have to wait for someone else to finish their job, do someone else's > job for them, or just have my deliverables look ugly (and most > higher-level managers I've dealt with don't usually like the "It's not > my fault/job!" answer...). you can tell your manager to give me a call land i'll set them straight. :) > Again, I agree with the concept, but not having any way to work around > it, *forcing* every possible application to fit within a pre-conceived > paradigm of how the platform should work, seems a little > over-restrictive and broken... that's the POINT of a widget set. the POINT of a toolkit. consistency. being usable DESPITE the programmer who really isn't considering such usability issues. it's the same as theme, fonts, and other factors. it's a global config value and to be set globally. if every app goes making its own themes, using its own fonts and sizes, then you end up with a mess. sure. it CAN be done. you just have to stop using edje and many parts of elementary and start manually stuffing things around the screen. the complexity of your app will go up a lot. that's INTENTIONAL. it's creating a technical barrier making you do immensely more work to "disagree" with the designs of the toolkit. it's there to discourage you from disagreeing. :) all of the elements obey these paradigms. all widgets that are to be interacted with set their minimum sizes based on visible content and finger size. edje respects minimum size hints as well thus making your entry the size it is. they are all "playing by the rules of the game". let me put this another way. if you said: my manager just won't understand that when i say "i can't do this - because normal user id's are not allowed. i need root access and have to wait for the XYZ team to finish creating a privileged access api via dbus before that can work", would you go to linus and say "hey linus. why don't you just drop this root privilege stuff. it makes my manager unhappy that i have to wait for others to grant my process controlled access to such features. i don't think your pre-conceived paradigm of how the platform should work is right"... would you do that? of course not! why does "security" get a free ride to be a pain in the butt and stop people and other factors like guaranteeing usability (or helping to) need to be able to be worked around trivially at any point? you might want to explain it that way to your "manager". > Thanks! > > -James > > > > >> Thanks! > >> > >> -James > >> > >> > > >> > -- > >> > Tom. > >> > > >> > On 07/10/11 02:45, Ausmus, James wrote: > >> >> Hi All- > >> >> > >> >> It appears that a standard Elementary entry widget has a minimum > >> >> height that it refuses to size beneath, regardless of the font size > >> >> being used, as demonstrated by the entry.c and entry.edc files below. > >> >> > >> >> Is there any way around this? How can I get a "short" Elm entry that > >> >> actually obeys the size of the swallow - do I need to fully grok and > >> >> recreate the default Elm theme for an entry in order to reduce the min > >> >>
Re: [E-devel] Elm entry sizing issue
On Mon, Oct 10, 2011 at 4:20 PM, Carsten Haitzler wrote: > On Mon, 10 Oct 2011 09:57:33 -0700 "Ausmus, James" > said: > >> On Fri, Oct 7, 2011 at 7:45 PM, Carsten Haitzler >> wrote: >> > On Fri, 7 Oct 2011 14:16:58 -0700 "Ausmus, James" >> > said: >> > >> >> On Fri, Oct 7, 2011 at 2:20 AM, Tom Hacohen wrote: >> >> > I'm away from home/computers until Saturday evening (leaving now), I'll >> >> > take a look at it soon after. >> >> > >> >> > But I have a couple of questions until then: >> >> > What sizing do you get? what do you expect? The elm minimum height >> >> > should change according to the font size (unless it's smaller than the >> >> > finger size, which is then used). >> >> >> >> It's taller than the part underneath it that it is set to be relative >> >> to and smaller than. However, I'm betting that the finger size thing >> >> is the issue here - any way to override/set the finger size >> >> dynamically, to be able to get around that limitation in one-off >> >> situations? >> > >> > use a label then, not entry. an entry is there for the purpose of entering >> > text or selecting it etc. - not just display. thus it forces it to be at >> > least a finger size in height for single line entries (for multiple line >> > its a bit nastier so it doesn't currently). the whole point of finger size >> > it to ensure a person can reliably press on it. if you have a desktop app >> > finger size should be globally on your system set to something low - like >> > "5". so you wont have a problem. but elm is fixing the ui to make it usable >> > for people. you don't need your ui test department now to tell you to fix >> > it anymore. :) >> >> >> Unfortunately, I need actual text entry, not just display. I agree >> that, if *everything* else on a given platform is working correctly, >> then the finger size should already be set at the appropriate value, >> and everything would work great. However, if there are other >> platform-level issues/misconfigurations/evolutions in play, I either >> have to wait for someone else to finish their job, do someone else's >> job for them, or just have my deliverables look ugly (and most >> higher-level managers I've dealt with don't usually like the "It's not >> my fault/job!" answer...). > > you can tell your manager to give me a call land i'll set them straight. :) Noted... :D > >> Again, I agree with the concept, but not having any way to work around >> it, *forcing* every possible application to fit within a pre-conceived >> paradigm of how the platform should work, seems a little >> over-restrictive and broken... > > that's the POINT of a widget set. the POINT of a toolkit. consistency. being > usable DESPITE the programmer who really isn't considering such usability > issues. it's the same as theme, fonts, and other factors. it's a global config > value and to be set globally. if every app goes making its own themes, using > its own fonts and sizes, then you end up with a mess. sure. it CAN be done. > you > just have to stop using edje and many parts of elementary and start manually > stuffing things around the screen. the complexity of your app will go up a > lot. > that's INTENTIONAL. it's creating a technical barrier making you do immensely > more work to "disagree" with the designs of the toolkit. it's there to > discourage you from disagreeing. :) all of the elements obey these paradigms. > all widgets that are to be interacted with set their minimum sizes based on > visible content and finger size. edje respects minimum size hints as well thus > making your entry the size it is. they are all "playing by the rules of the > game". I whole-heartedly agree with the idea that it should not be easy to override usability presets. However, making it essentially *impossible* to override the presets makes the widget set *less* useful, not more - I think that a toolkit should *strongly* discourage a developer from going "against the system", but, ultimately, if the developer really *needs* to do a single thing contrary to the preconceived paradigm, it should allow them - not trivially, because that, of course, almost encourages developers who don't know what they're doing to bypass the "rules" that have been set in place just to save them from themselves. In other words - what you're saying (from what I understand - please correct me if I'm wrong) is essentially: "We've considered *all* possible applications and uses of *all* of these widgets, and there is concretely *never* going to be a valid use case that doesn't fit in the paradigm of user interaction that we have created. We cover *everything* that could ever be - no one will *ever* have a valid use case that falls outside of what we have considered." With this particular application, I have this *one* case where, visually, I need an entry box that is a little shorter than what is currently (mis-, as the platform and emulation environment are certainly WIP) configured to be the minimum finger size. I have 99% of
Re: [E-devel] Elm entry sizing issue
On Tue, 11 Oct 2011 08:20:50 +0900 Carsten Haitzler (The Rasterman) wrote: > would you do that? of course not! why does "security" get a free ride > to be a pain in the butt and stop people and other factors like > guaranteeing usability (or helping to) need to be able to be worked > around trivially at any point? Coz security is supposed to be a pain in the arse? Usability is supposed to be as painless as possible? And managers are just a pain period. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- 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] Elm entry sizing issue
On Mon, 10 Oct 2011 16:45:13 -0700 "Ausmus, James" said: > On Mon, Oct 10, 2011 at 4:20 PM, Carsten Haitzler > wrote: > > On Mon, 10 Oct 2011 09:57:33 -0700 "Ausmus, James" > > said: > > > >> On Fri, Oct 7, 2011 at 7:45 PM, Carsten Haitzler > >> wrote: > >> > On Fri, 7 Oct 2011 14:16:58 -0700 "Ausmus, James" > >> > said: > >> > > >> >> On Fri, Oct 7, 2011 at 2:20 AM, Tom Hacohen wrote: > >> >> > I'm away from home/computers until Saturday evening (leaving now), > >> >> > I'll take a look at it soon after. > >> >> > > >> >> > But I have a couple of questions until then: > >> >> > What sizing do you get? what do you expect? The elm minimum height > >> >> > should change according to the font size (unless it's smaller than the > >> >> > finger size, which is then used). > >> >> > >> >> It's taller than the part underneath it that it is set to be relative > >> >> to and smaller than. However, I'm betting that the finger size thing > >> >> is the issue here - any way to override/set the finger size > >> >> dynamically, to be able to get around that limitation in one-off > >> >> situations? > >> > > >> > use a label then, not entry. an entry is there for the purpose of > >> > entering text or selecting it etc. - not just display. thus it forces it > >> > to be at least a finger size in height for single line entries (for > >> > multiple line its a bit nastier so it doesn't currently). the whole > >> > point of finger size it to ensure a person can reliably press on it. if > >> > you have a desktop app finger size should be globally on your system set > >> > to something low - like "5". so you wont have a problem. but elm is > >> > fixing the ui to make it usable for people. you don't need your ui test > >> > department now to tell you to fix it anymore. :) > >> > >> > >> Unfortunately, I need actual text entry, not just display. I agree > >> that, if *everything* else on a given platform is working correctly, > >> then the finger size should already be set at the appropriate value, > >> and everything would work great. However, if there are other > >> platform-level issues/misconfigurations/evolutions in play, I either > >> have to wait for someone else to finish their job, do someone else's > >> job for them, or just have my deliverables look ugly (and most > >> higher-level managers I've dealt with don't usually like the "It's not > >> my fault/job!" answer...). > > > > you can tell your manager to give me a call land i'll set them straight. :) > > Noted... :D > > > > >> Again, I agree with the concept, but not having any way to work around > >> it, *forcing* every possible application to fit within a pre-conceived > >> paradigm of how the platform should work, seems a little > >> over-restrictive and broken... > > > > that's the POINT of a widget set. the POINT of a toolkit. consistency. being > > usable DESPITE the programmer who really isn't considering such usability > > issues. it's the same as theme, fonts, and other factors. it's a global > > config value and to be set globally. if every app goes making its own > > themes, using its own fonts and sizes, then you end up with a mess. sure. > > it CAN be done. you just have to stop using edje and many parts of > > elementary and start manually stuffing things around the screen. the > > complexity of your app will go up a lot. that's INTENTIONAL. it's creating > > a technical barrier making you do immensely more work to "disagree" with > > the designs of the toolkit. it's there to discourage you from > > disagreeing. :) all of the elements obey these paradigms. all widgets that > > are to be interacted with set their minimum sizes based on visible content > > and finger size. edje respects minimum size hints as well thus making your > > entry the size it is. they are all "playing by the rules of the game". > > I whole-heartedly agree with the idea that it should not be easy to > override usability presets. However, making it essentially > *impossible* to override the presets makes the widget set *less* > useful, not more - I think that a toolkit should *strongly* discourage > a developer from going "against the system", but, ultimately, if the > developer really *needs* to do a single thing contrary to the > preconceived paradigm, it should allow them - not trivially, because > that, of course, almost encourages developers who don't know what > they're doing to bypass the "rules" that have been set in place just > to save them from themselves. > > In other words - what you're saying (from what I understand - please > correct me if I'm wrong) is essentially: "We've considered *all* > possible applications and uses of *all* of these widgets, and there is > concretely *never* going to be a valid use case that doesn't fit in > the paradigm of user interaction that we have created. We cover > *everything* that could ever be - no one will *ever* have a valid use > case that falls outside of what we have considered." > > With this particular applicatio
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
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 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
