Re: [E-devel] [PATCH] evas: reuse evas gl context and surface if change to new rotation
On Fri, 18 Jan 2013 02:37:07 + "Li, Peng" said: > Hi, enlightenment developers: > > Please help review attached patch and provide your comments. Thanks > > Peng so curious... what problems did you actually have? i am sure the code in there was conservative... and i've never noticed this as a problem. to be honest resizes in gl are abysmal already on a tonne of gl driver implementations (like slow as all hell). :) :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Sync vs Async: numbers!
On Thu, 17 Jan 2013 13:11:47 -0200 Leandro Pereira said: > Hey, > > Here are some numbers that show that the async renderer is actually > saving us time. These numbers can be obtained by yourself, by building > Evas with EVAS_RENDER_DEBUG_TIMING defined and setting/unsetting the > ECORE_EVAS_FORCE_SYNC_RENDER environment variable. > > This number is the measure, in ms, of the time spent during the Evas > rendering function. The average value is calculated every 100 calls. > > One can clearly see that the asynchronous renderer frees up a lot of > time in the main thread, in some cases using 10% of the time the > synchronous renderer needed: > > ⮀ export ECORE_EVAS_FORCE_SYNC_RENDER=1 > ⮀ elementary_test Animation > *** sync render: avg 2.978395ms min 0.947041ms max 30.379951ms > *** sync render: avg 1.957078ms min 0.474035ms max 4.538885ms > *** sync render: avg 1.872930ms min 0.760945ms max 4.978016ms > *** sync render: avg 1.724530ms min 0.906000ms max 3.591879ms > *** sync render: avg 1.902350ms min 0.627998ms max 14.931986ms > *** sync render: avg 1.692699ms min 0.940035ms max 3.616943ms > *** sync render: avg 1.754144ms min 0.834012ms max 5.288051ms > *** sync render: avg 1.699393ms min 0.899117ms max 3.489920ms > *** sync render: avg 1.887736ms min 0.519943ms max 9.911051ms > *** sync render: avg 1.775922ms min 0.989104ms max 3.373019ms > *** sync render: avg 1.712771ms min 0.714912ms max 4.344922ms > *** sync render: avg 1.752106ms min 0.918924ms max 4.158897ms > *** sync render: avg 1.754684ms min 0.486945ms max 3.843055ms > *** sync render: avg 1.853960ms min 0.92ms max 7.829068ms > *** sync render: avg 2.597078ms min 0.549895ms max 25.936982ms > ^C > ⮀ unset ECORE_EVAS_FORCE_SYNC_RENDER > ⮀ elementary_test Animation > *** async render: avg 1.705852ms min 0.105016ms max 32.549012ms > *** async render: avg 0.687507ms min 0.153924ms max 1.679043ms > *** async render: avg 0.364832ms min 0.146887ms max 1.703969ms > *** async render: avg 0.369488ms min 0.175889ms max 1.931037ms > *** async render: avg 0.367418ms min 0.151098ms max 2.927121ms > *** async render: avg 0.351177ms min 0.156086ms max 1.636885ms > *** async render: avg 0.353286ms min 0.163990ms max 1.528031ms > *** async render: avg 0.338158ms min 0.126063ms max 1.547922ms > *** async render: avg 0.355310ms min 0.168943ms max 1.684109ms > *** async render: avg 0.344575ms min 0.149928ms max 1.368967ms > *** async render: avg 0.351807ms min 0.101041ms max 1.538111ms > *** async render: avg 0.356258ms min 0.113084ms max 1.723979ms > *** async render: avg 0.357304ms min 0.174066ms max 1.776023ms > *** async render: avg 0.339344ms min 0.165109ms max 1.570926ms > ^C > > > > Less dramatic but still interesting results are visible with Terminology > running a redraw-intensive program such as the `aafire` demo from aalib: > > ⮀ unset ECORE_EVAS_FORCE_SYNC_RENDER > ⮀ terminology -e aafire -driver curses > *** async render: avg 1.949910ms min 0.320094ms max 6.811932ms > *** async render: avg 2.314617ms min 0.566074ms max 8.457115ms > *** async render: avg 2.440161ms min 0.544033ms max 8.315109ms > *** async render: avg 2.503508ms min 0.610092ms max 8.186047ms > *** async render: avg 2.339103ms min 0.586006ms max 9.791975ms > *** async render: avg 1.971868ms min 0.570879ms max 9.002959ms > *** async render: avg 2.698837ms min 0.558963ms max 11.941055ms > *** async render: avg 2.236830ms min 0.541988ms max 11.201896ms > ^C > ⮀ export ECORE_EVAS_FORCE_SYNC_RENDER=1 > ⮀ terminology -e aafire -driver curses > *** sync render: avg 4.777478ms min 0.809918ms max 12.482078ms > *** sync render: avg 5.043696ms min 2.887004ms max 11.873881ms > *** sync render: avg 4.810856ms min 2.514057ms max 11.527033ms > *** sync render: avg 4.873759ms min 2.718049ms max 9.166908ms > *** sync render: avg 5.406739ms min 2.945019ms max 28.283098ms > *** sync render: avg 5.224728ms min 2.833047ms max 12.698107ms > *** sync render: avg 5.378743ms min 2.787025ms max 13.941910ms > *** sync render: avg 4.993303ms min 2.939022ms max 11.360896ms > *** sync render: avg 5.065144ms min 2.356000ms max 13.610107ms > ^C argh! you confuzesedz me by orderign them differently per test.. had to look closely. :) i see you have found a good test/measuring stick to show how good async render is... :) ie time in evas_render() itself should be a fair bit less on average and spikes are hopefully reduced a lot. basically we have 16.6ms to generate a frame and get it to the screen. what we now have is much less of that counting on the app using minimal/no time in the mainloop AND frame generation logic uses up less time from the mainloop. for trivial examples (animation unfortunately is one) we actually shouldn't see much gain as time spent in "mainloop" is not much anyway... but for more involved apps this will basically not result in more fps really.. or not much.. but result in SMOOTHER fps... LESS frame-drops. :) this is good. nicely done. from here we now need to continue down
Re: [E-devel] async render + scalecache.. new segv fun
On Thu, 17 Jan 2013 20:34:40 -0200 Ulisses Furquim said: > Hi Raster, > > On Thu, Jan 17, 2013 at 11:13 AM, Ulisses Furquim > wrote: > > Hi Raster, > > > > We'll debug this. And yes, it should be scalecache and its pruning. > > Just sent a patch to fix these segmentation faults. It did fix for us > and we cannot reproduce anymore here. Please let us know in case you > hit another crash. so far, so good. let's see. i'll make noise if i find anything. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] evas: reuse evas gl context and surface if change to new rotation
Hi, enlightenment developers: Please help review attached patch and provide your comments. Thanks Peng reuse-evas-gl-context-and-surface-if-change-to-new-r.diff Description: reuse-evas-gl-context-and-surface-if-change-to-new-r.diff -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_X specific functions
On Fri, 18 Jan 2013 09:18:34 +0900 Daniel Juyung Seo said: > Yes this is a good idea. We need a wrapper layer for x and wayland. > Even ecore_evas will offer the APIs, we should consider usecases in > elementary applications. right now that wrapper layer is either ecore_evas (a very loose one) or it's elementary itself. trying to map every display system to another low-level api is generally really hard... as it stands elm does already deal with a chunk of this... and ecore-evas, the rest. so i'm wondering... what's the point here to make another api that will duplicate things... it has to be low-level to be used by ecore-evas, but this creates other issues. if it's high-level then it may as well be in elm? > Daniel Juyung Seo (SeoZ) > > On Fri, Jan 18, 2013 at 4:14 AM, Rafael Antognolli > wrote: > > Yes, if it's exposed through ecore_evas, then it will allow usage > > outside of elementary. > > > > On Thu, Jan 17, 2013 at 3:17 PM, Christopher Michael > > wrote: > >> While still allowing usage Outside of Elementary (one would hope) > >> > >> dh > >> > >> Rafael Antognolli wrote: > >>> > >>> On Thu, Jan 17, 2013 at 2:49 PM, Gustavo Sverzut Barbieri > >>> wrote: > > On Thu, Jan 17, 2013 at 2:43 PM, Michael Blumenkrantz > wrote: > > > > On Thu, 17 Jan 2013 14:39:17 -0200 > > Rafael Antognolli wrote: > > > >> Hi all, > >> > >> Ecore_X have been around for some time already. It's a library that > >> allows us to write code not covered by Ecore_Evas API, but that it's > >> specific to X. > >> > >> However, since it's all inside > >> EFL, wouldn't it be possible to have a > >> layer on top of Ecore_X, that exposes thoses APIs, but that allows us > >> to have different implementations (e.g. for different backends)? Or > >> maybe just move those calls which seem to be generic enough to > >> Ecore_Evas? > >> > >> I'm referring to things like DND, selection, DPI get, screen info, > >> etc. Maybe some of them are already in a common place, but I'm sure > >> that there are more things to be moved/changed. > > > > > > > > you mean, perhaps, something like ecore_evas? > > > > Indeed, it's a best fit for ecore_evas. Now that we have wayland and x > it's time to make an uniform API for these things. Maybe based on > Elementary's usage? > >>> > >>> > >>> Yep, that would be a good start. > >>> > >>> -- > >>> Rafael Antognolli > >>> http://antognolli.org/ > >>> > >>> > >>> > >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > >>> MVC, > >>> Windows 8 Apps, JavaScript and much more. Keep your skills current > >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > >>> MVPs and experts. ON SALE this month only -- learn more at: > >>> http://p.sf.net/sfu/learnmore_122712 > >>> > >>> > >>> enlightenment-devel mailing list > >>> enlightenment-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > -- > > Rafael Antognolli > > http://antognolli.org/ > > > > -- > > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > > MVPs and experts. ON SALE this month only -- learn more at: > > http://p.sf.net/sfu/learnmore_122712 > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > ___ > 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 -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.source
Re: [E-devel] issues with a recent e17
I can confirm the suspend problem and the new window desktop focus. The systray module produces different results for me. Some icons are whatever the program has put there. Others appear to be replaced with icons and menus that e creates. And a third group has both the app supplied icon, and the e replacement one (network manager falls into this category) On Jan 18, 2013 1:11 AM, "Massimo Maiurana" wrote: > here are some problems I have with trunk e17+efl (82865): > > - I resume from suspend to ram, write my password in desklock and I have > e17 > running; all looks fine, but after a few seconds the laptop goes again in > suspend to ram. Again, I resume it, write my password, e starts for a few > seconds and suspend again. I have to restart e (ctrl+alt+end) to prevent > it to > suspend again. > - no matter if I check or uncheck "Switch to desktop of new window" in the > config panel, every time a new window, or a new firefox tab, appears e > switches to that desktop. > - systray doesn't work anymore. when I run pidgin I see no icons in > systray, > but when I run mumble it is even worst, because I get an icon which is the > mumble tray icon (if I click on it I get the mumble menu), but it isn't in > systray nor it has the mumble icon. instead it goes over the start button > and > it has a "forbidden" icon (see the image attached, it's in the lower left > corner). > > also, with the previous versions I had the timeout for desklock set to 5 > minutes, but when I had a fullscreen window, tipically a movie inside > mplayer, > e did never go locking, just as it was in presentation mode. now it is not > so > anymore, and I haven't found a config option to set it again to that > behaviour. am I missing something? > > -- > > Massimo Maiurana GPG keyID #7044D601 > > La fede e' credere in cio' che sai non essere vero > [Mark Twain] > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Sync vs Async: numbers!
On Fri, Jan 18, 2013 at 12:45 AM, Gustavo Sverzut Barbieri wrote: > On Thu, Jan 17, 2013 at 1:11 PM, Leandro Pereira > wrote: >> Hey, >> >> Here are some numbers that show that the async renderer is actually >> saving us time. These numbers can be obtained by yourself, by building >> Evas with EVAS_RENDER_DEBUG_TIMING defined and setting/unsetting the >> ECORE_EVAS_FORCE_SYNC_RENDER environment variable. >> >> This number is the measure, in ms, of the time spent during the Evas >> rendering function. The average value is calculated every 100 calls. >> >> One can clearly see that the asynchronous renderer frees up a lot of >> time in the main thread, in some cases using 10% of the time the >> synchronous renderer needed: >> >> ⮀ export ECORE_EVAS_FORCE_SYNC_RENDER=1 > [...] >> *** sync render: avg 1.754684ms min 0.486945ms max 3.843055ms >> *** sync render: avg 1.853960ms min 0.92ms max 7.829068ms >> *** sync render: avg 2.597078ms min 0.549895ms max 25.936982ms > [...] >> ⮀ unset ECORE_EVAS_FORCE_SYNC_RENDER >> *** async render: avg 0.356258ms min 0.113084ms max 1.723979ms >> *** async render: avg 0.357304ms min 0.174066ms max 1.776023ms >> *** async render: avg 0.339344ms min 0.165109ms max 1.570926ms > > Yes, that's the kind of gain we expected from async render. As there > is no magic, you end doing MORE work to delegate to the thread, but > you have more predictable time spend on the main thread (min closer to > max, average is more constant). The problem with this is that the added overhead is likely to increase power consumption. That's why we still have some optimization to do and async rendering open us a lot of possible speed improvement. For desktop use it's already a clear win in my opinion. > As the async render will "drop" frames per design (it will keep queue > full, but will not stop to render all requested frames, effectively > dropping some render() calls at no visual loss), your application will > always behave more smoothly, being able to interact with user input > more often. > > As for the predictable part, it's still not fixed in time, but we can > determine the time it will spend on the main thread > > - Async: > - Main Thread: depends on number of objects > - Render Thread: depends on number of objects AND output size > - Sync: main thread depends on number of objects AND output size > > Test hint: one can induce slowness by running with valgrind. The async > version behaves more smoothly than the other :-) > > Win! \o/ Is E17 usable under valgrind now ? :-D Just kidding... wait I should try that ! -- Cedric BAIL -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Fri, Jan 18, 2013 at 12:34 AM, Gustavo Sverzut Barbieri wrote: > On Thu, Jan 17, 2013 at 12:15 PM, Cedric BAIL wrote: >> On Thu, Jan 17, 2013 at 10:34 PM, Gustavo Sverzut Barbieri >> wrote: >>> On Thursday, January 17, 2013, Cedric BAIL wrote: On Thu, Jan 17, 2013 at 9:37 PM, Gustavo Sverzut Barbieri > wrote: > On Thursday, January 17, 2013, Cedric BAIL wrote: >> On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri >> > wrote: >> > On Thursday, January 17, 2013, Enlightenment SVN wrote: >> >> Log: >> >> efl: stupid micro optimization. >> >> >> >> This single test accounted for 1% of my terminology benchmark. >> >> I am considering moving evas_string_char_next_get and >> >> eina_unicode_utf8_get_next to become inline as their function >> >> entry/exit point account for 3% of the same benchmark. >> >> >> >> The biggest win would be to get rid of the memcpy _termpty_text_copy >> >> that account for 16%. >> >> >> >> In the micro optimization part, we also still do to much malloc >> >> in font_draw_prepare as we don't recycle the array there and account >> >> for 3% of the benchmark in malloc/free there. In the same ballpark >> >> _text_save_top account for 2% of the time in malloc/free. >> >> >> >> In that same benchmark, evas_object_textgrid_render account for 5% >> >> where 4% of its time is spend in evas_common_font_draw_prepare. At >> this >> >> point I am not sure that rewriting textgrid is gona help us at all. We >> >> will win almost as much by just inlining the get_next things in evas >> >> and eina for a minute of development time. >> > >> > It's a bit naive to think so, because you'd be able to change the >> algorithm >> > and avoid conversions. All in all you could just give engine the same >> array >> > that terminology fills (cell row array), together with region and context >> > (clipper, cutouts) and glyph bitmap. >> > >> > Particularly the glyph bitmap could be optimized as its an int hash, but >> we >> > know A-Za-z0-9 ate hot, we could have ASCII printable range in an array >> > while everything else goes to a hash >> >> Time spend in evas_common_font_draw 4%. Time spend in >> evas_object_textgrid_*: > 2%. >> Time spend in _cb_fb_read : 82% with evas_string_char_next_get being >> 15% and memcpy 18%. >> >> I don't see how optimizing textgrid is going to change this number at all. > > You'd not be doing these at all. That's why/how. What do you mean by "these" ? I am going to redo the benchmark with perf on another computer to see if there is something else. >>> >>> >>> These calls. If you do the way I imagine you give the screen (array of >>> cells) to the render much like the way you give pixels to image. There is >>> no need to call a bunch of things, like no need to create the text props >>> and such. All you need is the cell info (palette index and attributes), the >>> palette contents and a way to convert Unicode -> bitmap. >> >> All the cost of this 4% goes into the blitting, that you can't win. So >> you are basically going after a 2% improvement, that you can maybe >> reduce a little but not much as we don't create the text props at all >> in more than 99% of the case and the text props is a mapping from >> unicode to bitmap that are recycled very often. I really think you are >> focusing on the wrong thing here. > > You can allow engine to cache not only the glyphs, but the cells. > (with bg/font colors, translating into pure image blit). Text grid is > pretty cache friendly for one alphabet, and for terminology that will > definitely hit ASCII as user data may be outside it, but compile > output, commands and similar are all ASCII :-) You can have an array > of printable elements and access them in O(1), no translation. Now, I get it ! Ok, we could basically save maybe a half of this 2% and move the rest into the rendering thread (as it is still required to walk over the grid). So I now do understand your idea. > And if you do such, the grid contents needs no special handling. It > will be like an image, you can think about an image with different > colorspace :-) > > as for the _cb_fd_read(), indeed it's outside of the concept of > textgrid... and looking at it it's pretty obvious that should > optimizations could be applied, simply by changing how it converts the > chars to unicode, then handle it to handle_buf just to grow its buffer > and copy. The (n == 0) block can also be simplified and optimized at > the same time :-) That's where we should focus. Once done there, optimizing the textgrid may give us some speedup, but right now this part is hiding everything. -- Cedric BAIL
Re: [E-devel] Ecore_X specific functions
Yes this is a good idea. We need a wrapper layer for x and wayland. Even ecore_evas will offer the APIs, we should consider usecases in elementary applications. Daniel Juyung Seo (SeoZ) On Fri, Jan 18, 2013 at 4:14 AM, Rafael Antognolli wrote: > Yes, if it's exposed through ecore_evas, then it will allow usage > outside of elementary. > > On Thu, Jan 17, 2013 at 3:17 PM, Christopher Michael > wrote: >> While still allowing usage Outside of Elementary (one would hope) >> >> dh >> >> Rafael Antognolli wrote: >>> >>> On Thu, Jan 17, 2013 at 2:49 PM, Gustavo Sverzut Barbieri >>> wrote: On Thu, Jan 17, 2013 at 2:43 PM, Michael Blumenkrantz wrote: > > On Thu, 17 Jan 2013 14:39:17 -0200 > Rafael Antognolli wrote: > >> Hi all, >> >> Ecore_X have been around for some time already. It's a library that >> allows us to write code not covered by Ecore_Evas API, but that it's >> specific to X. >> >> However, since it's all inside >> EFL, wouldn't it be possible to have a >> layer on top of Ecore_X, that exposes thoses APIs, but that allows us >> to have different implementations (e.g. for different backends)? Or >> maybe just move those calls which seem to be generic enough to >> Ecore_Evas? >> >> I'm referring to things like DND, selection, DPI get, screen info, >> etc. Maybe some of them are already in a common place, but I'm sure >> that there are more things to be moved/changed. > > > > you mean, perhaps, something like ecore_evas? Indeed, it's a best fit for ecore_evas. Now that we have wayland and x it's time to make an uniform API for these things. Maybe based on Elementary's usage? >>> >>> >>> Yep, that would be a good start. >>> >>> -- >>> Rafael Antognolli >>> http://antognolli.org/ >>> >>> >>> >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, >>> Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnmore_122712 >>> >>> >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Rafael Antognolli > http://antognolli.org/ > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Error building efl/
On Fri, 18 Jan 2013 00:50:28 +0200 "Alex-P. Natsios" said: > On Wed, Jan 16, 2013 at 1:15 PM, Carsten Haitzler > wrote: > > > all we can do is ensure at least its least broken for those that work on the > > src itself and ... :/ > > thing is an automated way did not work even for those who actively > work/ed on the code. > it wasn't just platform but also autotools dependent. over the past 16+ years i've learned that: 1. autotools likes to upgrade regularly from 1.xx to 1.yy and so on 2. as it upgrades it often creates brekages, deprecates stuff and breaks it etc. 3. you often can't just choose any combination of versions of automake + autoconf + libtool + gettext etc. - you need a "magic working combo" 4. reality is that "we make it work for us". until "us" is the most number of devs. what the above magic combos are changes over time, and then a year goes by and it's all good and then suddenly some distro revs, upgrades these tools and everyone is bitching that things don't build anymore because they upgrade within days or weeks of the new distro release. re-running autotools is something DEVS do. our job is to produce tarballs that dont need to run autotools. so it must work for us. we work on the code every day and produce such tarballs. reality is we CANNOT make it work for everyone. well not from the "run autotools" point. our job is to make TARBALLS that work for everyone. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . licenses
On Thu, 17 Jan 2013 13:51:16 -0200 Gustavo Sverzut Barbieri said: > On Thu, Jan 17, 2013 at 1:03 AM, Carsten Haitzler > wrote: > > On Wed, 16 Jan 2013 22:50:08 -0200 Gustavo Sverzut Barbieri > > said: > > > >> On Wednesday, January 16, 2013, David Seikel wrote: > >> > >> > On Wed, 16 Jan 2013 13:48:14 -0800 "Enlightenment SVN" > >> > > wrote: > >> > > >> > > Log: > >> > > add missing licenses references, fix copyright, add link result > >> > > notice. > >> > > > >> > > Author: barbieri > >> > > Date: 2013-01-16 13:48:14 -0800 (Wed, 16 Jan 2013) > >> > > New Revision: 82911 > >> > > Trac: http://trac.enlightenment.org/e/changeset/82911 > >> > > > >> > > Modified: > >> > > trunk/efl/COPYING trunk/efl/licenses/COPYING.BSD > >> > > trunk/efl/licenses/COPYING.LGPL > >> > > > >> > > Modified: trunk/efl/COPYING > >> > > === > >> > > --- trunk/efl/COPYING 2013-01-16 21:47:37 UTC (rev 82910) > >> > > +++ trunk/efl/COPYING 2013-01-16 21:48:14 UTC (rev 82911) > >> > > @@ -1,11 +1,23 @@ > >> > > -EFL comes with several licences. Listed are the library/probject > >> > > +EFL comes with several licences. Listed are the library/project > >> > > name and the license file covering it. > >> > > > >> > > evil:licenses/COPYING.BSD > >> > > -escape: licenses/COPYING.GPL > >> > > +escape: licenses/COPYING.GPL (used in PlayStation native) > >> > > +eina:licenses/COPYING.LGPL > >> > > eet: licenses/COPYING.BSD > >> > > -eina:licenses/COPYING.LGPL > >> > > eo: licenses/COPYING.BSD > >> > > evas:licenses/COPYING.BSD > >> > > +embryo: licenses/COPYING.SMALL > >> > > ecore: licenses/COPYING.BSD > >> > > -embryo: licenses/COPYING.SMALL > >> > > +eio: licenses/COPYING.LGPL > >> > > +edbus: licenses/COPYING.LGPL > >> > > +efreet: licenses/COPYING.BSD > >> > > +eeze:licenses/COPYING.BSD > >> > > +ephysics:licenses/COPYING.BSD > >> > > +edje:licenses/COPYING.BSD > >> > > +edje/epp:licenses/COPYING.GPL (separate binary/executable) > >> > > +emotion: licenses/COPYING.BSD > >> > > +ethumb: licenses/COPYING.LGPL > >> > > + > >> > > +NOTE: If linked together, the result will be LGPL (or GPL is Escape > >> > > is +used) due that license characteristics. > >> > > >> > Hmmm, guess that means the BSD licences are useless, since it's all > >> > gonna be linked together anyway, and thus GPL contaminated. > >> > >> > >> That is right. For all purposes consider EFL = LGPL. We just didn't change > >> the license as it would require approvals. But effectively it's all LGPL. > > > > incorrect. only if we make a single libefl.so is this the case. > > The on-disk .so files are not, but as soon as they are dynamically > linked in the application they do that. Unfortunately I had to learn > that with some lawyers :-P they don't make your application lgpl. that dont make it gpl. they dont make it bsd. they dont affect your application at all... unless you STATICALLY link... lgpl is very explicit about its boundaries. GPL - yes. LGPL - no. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje external elm/entry's editable parameter
On Thu, 17 Jan 2013 20:03:18 -0200 Bruno Dilly said: > On Thu, Jan 17, 2013 at 7:41 PM, Bruno Dilly wrote: > > On Tue, Jan 15, 2013 at 1:09 AM, Leif Middelschulte > > wrote: > >> Hello everyone, > >> > >> I'm trying to use an elm_entry for a UI via edje externals. > >> Unfortunatelly, the entries don't respect the 'editable' parameter. > >> I've attached an edc example, hoping that I've just been doing something > >> wrong. > >> > > > > Hey Leif, > > > > interesting issue. But looks like editable parameter is respected, if > > you set it to "1", you can cut text, if it's set to "0", you can't. > > Btw, entries are editable by default. > > > > I guess it's an issue related to focus, and it exists on 1.7.x too. > > And it's not specific to entries. Other stuff swallowed won't be > focused as well. > You can try to add a button, it won't be focused after you press it > (you could try to press spacebar to activate it). > > But for entries it's a major issue. the moment you use externals.. or an edje object by hand, you break elm's focus chain. > >> -- > >> > >> Leif > >> > >> -- > >> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS > >> and more. Get SQL Server skills now (including 2012) with LearnDevNow - > >> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > >> SALE $99.99 this month only - learn more at: > >> http://p.sf.net/sfu/learnmore_122512 > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > > > -- > > Bruno Dilly > > Lead Developer > > ProFUSION embedded systems > > http://profusion.mobi > > > > -- > Bruno Dilly > Lead Developer > ProFUSION embedded systems > http://profusion.mobi > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > 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 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . licenses
On Fri, 18 Jan 2013 02:48:23 +1000 David Seikel said: > On Thu, 17 Jan 2013 14:12:29 -0200 Gustavo Sverzut Barbieri > wrote: > > > On Thu, Jan 17, 2013 at 1:36 AM, David Seikel > > wrote: > > >> Well, the resulting license is different. Indeed it will be LGPL. > > >> But say you take Evas and remove eina dep, you could use that as > > >> BSD. > > > > > There is nothing related to virus other than FUD > > You said so yourself, the BSD licensed parts of EFL are now effectively > LGPL licensed. That's not FUD, that's viral. > > > BSD says nothing other than you must retain its copyright when you > > distribute its source code. It's fully a subset of LGPL, as so LGPL is > > more restrictive, extending with more clauses. > > BSD does not say anything about restricting the right to copy in the > way LGPL does. It's a copyright licence, as such, it reflects the > desires of the copyright owner and is a legal document. A third party > is not allowed to further restrict those copyrights, they simply do > not have that right. It's legal rights, not code, we don't get to > refactor things to our liking like that. lol you could argue then that your placing a restriction of "you pay me and then you get this code" is violating bsd. stop violating it you evil man! copyright is absolute ownership. no one has a right to copy copyrighted work EXCEPT if given permission by the copyright owner. the license is granting people such permissions... given you adhere to certain conditions. the conditions bsd gives are few and far between... and so you are free to ADD restrictions on top as it does not forbid them and so long as they do not conflict with the minimal conditions it already has set. LGPL and even GPL do not interfere with those conditions. seriously - read up on some legal opinions here. we can debate this virus thing all u like but its pointless. if we dont allow lgpl many devs wont contribute. as gustavo said - we cant sensibly relicense lgpl->bsd. we are respecting the wishes of the developers doing the contribution. for sanity we have had to limit the license per lib to "stick to the license of this lib please so it doesn't become "file x has license a, file y license b etc.". except for a few "contained" exceptions (epp, small). your ranting about lgpl being viral is totally uninformed. it's FUD spreading. lgpl clearly defines a limited container for its license - and that is the shared library binary that is produced (in the simplest form - it goes on to define how this boundary looks. gpl (for libs) is viral. bsd requires you (and thus also your clients) to adhere to its demands. that is to reproduce that copyright notice. lgpl simply adds that they ALSO produce the source for that library too alongside the copyright notice, including any changes made to it - ie the EXACT source used to build the binaries they use. it also pretty much asks them to not statically compile the library into their binaries (be they other libraries or just executables). WE in the efl world ALSO pretty much say the same even of bsd libs - dont statically compile please. we USE library file locations that we derive FROM the binary that owns the symbols of evas, eina, edje etc. to FIND things like data files, modules etc. so we push towards this for technical reasons - and there is nothing incompatible or bad about lgpl pushing towards the same goal effectively. maybe you should explain it this way - lgpl is just these simplified extensions on bsd - attach the exact src used to produce that shared lib along with the already required license/copyright notice AND don't statically link. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Error building efl/
On Wed, Jan 16, 2013 at 1:15 PM, Carsten Haitzler wrote: > all we can do is ensure at least its least broken for those that work on the > src itself and ... :/ thing is an automated way did not work even for those who actively work/ed on the code. it wasn't just platform but also autotools dependent. -- Regards, Alex-P. Natsios (a.k.a Drakevr) -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] async render + scalecache.. new segv fun
Hi Raster, On Thu, Jan 17, 2013 at 11:13 AM, Ulisses Furquim wrote: > Hi Raster, > > We'll debug this. And yes, it should be scalecache and its pruning. Just sent a patch to fix these segmentation faults. It did fix for us and we cannot reproduce anymore here. Please let us know in case you hit another crash. Thanks, -- Ulisses Furquim ProFUSION embedded systems http://profusion.mobi Mobile: +55 19 9250 0942 Skype: ulissesffs -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje external elm/entry's editable parameter
On Thu, Jan 17, 2013 at 7:41 PM, Bruno Dilly wrote: > On Tue, Jan 15, 2013 at 1:09 AM, Leif Middelschulte > wrote: >> Hello everyone, >> >> I'm trying to use an elm_entry for a UI via edje externals. >> Unfortunatelly, the entries don't respect the 'editable' parameter. >> I've attached an edc example, hoping that I've just been doing something >> wrong. >> > > Hey Leif, > > interesting issue. But looks like editable parameter is respected, if > you set it to "1", you can cut text, if it's set to "0", you can't. > Btw, entries are editable by default. > > I guess it's an issue related to focus, and it exists on 1.7.x too. And it's not specific to entries. Other stuff swallowed won't be focused as well. You can try to add a button, it won't be focused after you press it (you could try to press spacebar to activate it). But for entries it's a major issue. > >> -- >> >> Leif >> >> -- >> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS >> and more. Get SQL Server skills now (including 2012) with LearnDevNow - >> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. >> SALE $99.99 this month only - learn more at: >> http://p.sf.net/sfu/learnmore_122512 >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > > -- > Bruno Dilly > Lead Developer > ProFUSION embedded systems > http://profusion.mobi -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje external elm/entry's editable parameter
On Tue, Jan 15, 2013 at 1:09 AM, Leif Middelschulte wrote: > Hello everyone, > > I'm trying to use an elm_entry for a UI via edje externals. > Unfortunatelly, the entries don't respect the 'editable' parameter. > I've attached an edc example, hoping that I've just been doing something > wrong. > Hey Leif, interesting issue. But looks like editable parameter is respected, if you set it to "1", you can cut text, if it's set to "0", you can't. Btw, entries are editable by default. I guess it's an issue related to focus, and it exists on 1.7.x too. > -- > > Leif > > -- > Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS > and more. Get SQL Server skills now (including 2012) with LearnDevNow - > 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only - learn more at: > http://p.sf.net/sfu/learnmore_122512 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_X specific functions
Yes, if it's exposed through ecore_evas, then it will allow usage outside of elementary. On Thu, Jan 17, 2013 at 3:17 PM, Christopher Michael wrote: > While still allowing usage Outside of Elementary (one would hope) > > dh > > Rafael Antognolli wrote: >> >> On Thu, Jan 17, 2013 at 2:49 PM, Gustavo Sverzut Barbieri >> wrote: >>> >>> On Thu, Jan 17, 2013 at 2:43 PM, Michael Blumenkrantz >>> wrote: On Thu, 17 Jan 2013 14:39:17 -0200 Rafael Antognolli wrote: > Hi all, > > Ecore_X have been around for some time already. It's a library that > allows us to write code not covered by Ecore_Evas API, but that it's > specific to X. > > However, since it's all inside > EFL, wouldn't it be possible to have a > layer on top of Ecore_X, that exposes thoses APIs, but that allows us > to have different implementations (e.g. for different backends)? Or > maybe just move those calls which seem to be generic enough to > Ecore_Evas? > > I'm referring to things like DND, selection, DPI get, screen info, > etc. Maybe some of them are already in a common place, but I'm sure > that there are more things to be moved/changed. you mean, perhaps, something like ecore_evas? >>> >>> >>> >>> Indeed, it's a best fit for ecore_evas. Now that we have wayland and x >>> it's time to make an uniform API for these things. Maybe based on >>> Elementary's usage? >> >> >> Yep, that would be a good start. >> >> -- >> Rafael Antognolli >> http://antognolli.org/ >> >> >> >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, >> Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122712 >> >> >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli http://antognolli.org/ -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_X specific functions
While still allowing usage Outside of Elementary (one would hope) dh Rafael Antognolli wrote: >On Thu, Jan 17, 2013 at 2:49 PM, Gustavo Sverzut Barbieri > wrote: >> On Thu, Jan 17, 2013 at 2:43 PM, Michael Blumenkrantz >> wrote: >>> On Thu, 17 Jan 2013 14:39:17 -0200 >>> Rafael Antognolli wrote: >>> Hi all, Ecore_X have been around for some time already. It's a library that allows us to write code not covered by Ecore_Evas API, but that >it's specific to X. However, since it's all inside EFL, wouldn't it be possible to have >a layer on top of Ecore_X, that exposes thoses APIs, but that allows >us to have different implementations (e.g. for different backends)? Or maybe just move those calls which seem to be generic enough to Ecore_Evas? I'm referring to things like DND, selection, DPI get, screen info, etc. Maybe some of them are already in a common place, but I'm sure that there are more things to be moved/changed. >>> >>> you mean, perhaps, something like ecore_evas? >>> >> >> Indeed, it's a best fit for ecore_evas. Now that we have wayland and >x >> it's time to make an uniform API for these things. Maybe based on >> Elementary's usage? > >Yep, that would be a good start. > >-- >Rafael Antognolli >http://antognolli.org/ > >-- >Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >MVPs and experts. ON SALE this month only -- learn more at: >http://p.sf.net/sfu/learnmore_122712 >___ >enlightenment-devel mailing list >enlightenment-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] heavy cpu usage with edje_example.c
On Thu, Jan 17, 2013 at 3:10 PM, Gustavo Sverzut Barbieri wrote: > On Thu, Jan 17, 2013 at 2:03 PM, Arvind R wrote: >> Hi, >> >> Just started with edje_example.[c,edc] as starting point of a >> video-asset-managemnt system I need. After the first time the mouse >> goes over the text, and the text changes colour, I just parked the >> mouse in the window (not over the text). System fan alerted me to >> something amiss. Top shows 70% for enlightenment, 60% for >> edje_example, and 35% for Xorg. >> This is crazy! 4/5 years ago (when entrance was available) I had >> emotion, edje combo for a video-monitor program that had 6 videos >> playing with sound-activated on focus and simple VU-meter for every >> video running simultaneously on a dual-core with capacity to spare! >> >> The system is a quad-core Core2. E is svn82296. Graphics is pretty >> recent nouveau. >> >> What's wrong? > > Hi Arvind, you're the one to spot bugs! > > I've asked bdilly to test this and indeed it's bogus... only on SVN! > The 1.7 works all right, so it's a regression that is triggering TEXT > parts to emit "mouse,in" and "mouse,out". Rectangle and others are > fine. Adding a bit more information: this issue doesn't happen if the transition is removed. So it looks pretty specific. It's a text part that changes its state (with transition) when it emits mouse,in and mouse,out. Easy to check just building edje_example edj an running with edje_player -p. Regards > > I'm CCíng e-devel, maybe someone there will know who changed related bits. > > Regards, > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bruno Dilly Lead Developer ProFUSION embedded systems http://profusion.mobi -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] heavy cpu usage with edje_example.c
On Thu, Jan 17, 2013 at 2:03 PM, Arvind R wrote: > Hi, > > Just started with edje_example.[c,edc] as starting point of a > video-asset-managemnt system I need. After the first time the mouse > goes over the text, and the text changes colour, I just parked the > mouse in the window (not over the text). System fan alerted me to > something amiss. Top shows 70% for enlightenment, 60% for > edje_example, and 35% for Xorg. > This is crazy! 4/5 years ago (when entrance was available) I had > emotion, edje combo for a video-monitor program that had 6 videos > playing with sound-activated on focus and simple VU-meter for every > video running simultaneously on a dual-core with capacity to spare! > > The system is a quad-core Core2. E is svn82296. Graphics is pretty > recent nouveau. > > What's wrong? Hi Arvind, you're the one to spot bugs! I've asked bdilly to test this and indeed it's bogus... only on SVN! The 1.7 works all right, so it's a regression that is triggering TEXT parts to emit "mouse,in" and "mouse,out". Rectangle and others are fine. I'm CCíng e-devel, maybe someone there will know who changed related bits. Regards, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_X specific functions
On Thu, Jan 17, 2013 at 2:49 PM, Gustavo Sverzut Barbieri wrote: > On Thu, Jan 17, 2013 at 2:43 PM, Michael Blumenkrantz > wrote: >> On Thu, 17 Jan 2013 14:39:17 -0200 >> Rafael Antognolli wrote: >> >>> Hi all, >>> >>> Ecore_X have been around for some time already. It's a library that >>> allows us to write code not covered by Ecore_Evas API, but that it's >>> specific to X. >>> >>> However, since it's all inside EFL, wouldn't it be possible to have a >>> layer on top of Ecore_X, that exposes thoses APIs, but that allows us >>> to have different implementations (e.g. for different backends)? Or >>> maybe just move those calls which seem to be generic enough to >>> Ecore_Evas? >>> >>> I'm referring to things like DND, selection, DPI get, screen info, >>> etc. Maybe some of them are already in a common place, but I'm sure >>> that there are more things to be moved/changed. >>> >> >> you mean, perhaps, something like ecore_evas? >> > > Indeed, it's a best fit for ecore_evas. Now that we have wayland and x > it's time to make an uniform API for these things. Maybe based on > Elementary's usage? Yep, that would be a good start. -- Rafael Antognolli http://antognolli.org/ -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_X specific functions
On Thu, Jan 17, 2013 at 2:43 PM, Michael Blumenkrantz wrote: > On Thu, 17 Jan 2013 14:39:17 -0200 > Rafael Antognolli wrote: > >> Hi all, >> >> Ecore_X have been around for some time already. It's a library that >> allows us to write code not covered by Ecore_Evas API, but that it's >> specific to X. >> >> However, since it's all inside EFL, wouldn't it be possible to have a >> layer on top of Ecore_X, that exposes thoses APIs, but that allows us >> to have different implementations (e.g. for different backends)? Or >> maybe just move those calls which seem to be generic enough to >> Ecore_Evas? >> >> I'm referring to things like DND, selection, DPI get, screen info, >> etc. Maybe some of them are already in a common place, but I'm sure >> that there are more things to be moved/changed. >> > > you mean, perhaps, something like ecore_evas? > Indeed, it's a best fit for ecore_evas. Now that we have wayland and x it's time to make an uniform API for these things. Maybe based on Elementary's usage? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . licenses
On Thu, 17 Jan 2013 14:12:29 -0200 Gustavo Sverzut Barbieri wrote: > On Thu, Jan 17, 2013 at 1:36 AM, David Seikel > wrote: > >> Well, the resulting license is different. Indeed it will be LGPL. > >> But say you take Evas and remove eina dep, you could use that as > >> BSD. > There is nothing related to virus other than FUD You said so yourself, the BSD licensed parts of EFL are now effectively LGPL licensed. That's not FUD, that's viral. > BSD says nothing other than you must retain its copyright when you > distribute its source code. It's fully a subset of LGPL, as so LGPL is > more restrictive, extending with more clauses. BSD does not say anything about restricting the right to copy in the way LGPL does. It's a copyright licence, as such, it reflects the desires of the copyright owner and is a legal document. A third party is not allowed to further restrict those copyrights, they simply do not have that right. It's legal rights, not code, we don't get to refactor things to our liking like that. lol -- 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 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore_X specific functions
On Thu, 17 Jan 2013 14:39:17 -0200 Rafael Antognolli wrote: > Hi all, > > Ecore_X have been around for some time already. It's a library that > allows us to write code not covered by Ecore_Evas API, but that it's > specific to X. > > However, since it's all inside EFL, wouldn't it be possible to have a > layer on top of Ecore_X, that exposes thoses APIs, but that allows us > to have different implementations (e.g. for different backends)? Or > maybe just move those calls which seem to be generic enough to > Ecore_Evas? > > I'm referring to things like DND, selection, DPI get, screen info, > etc. Maybe some of them are already in a common place, but I'm sure > that there are more things to be moved/changed. > > Regards, > -- > Rafael Antognolli > http://antognolli.org/ > you mean, perhaps, something like ecore_evas? -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_X specific functions
Hi all, Ecore_X have been around for some time already. It's a library that allows us to write code not covered by Ecore_Evas API, but that it's specific to X. However, since it's all inside EFL, wouldn't it be possible to have a layer on top of Ecore_X, that exposes thoses APIs, but that allows us to have different implementations (e.g. for different backends)? Or maybe just move those calls which seem to be generic enough to Ecore_Evas? I'm referring to things like DND, selection, DPI get, screen info, etc. Maybe some of them are already in a common place, but I'm sure that there are more things to be moved/changed. Regards, -- Rafael Antognolli http://antognolli.org/ -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . licenses
On Thu, Jan 17, 2013 at 1:36 AM, David Seikel wrote: >> Well, the resulting license is different. Indeed it will be LGPL. But >> say you take Evas and remove eina dep, you could use that as BSD. >> >> I'd personally prefer to have everything as LGPL, but to change each >> piece/file requires copyright holder approval. > > I'd personally prefer the exact opposite. Note that changing the small > number of LGPL bits to BSD would be easier, since there's less of it. > B-) Less of it but less people willing to do so. I have lots of chunk of code in Eina, Evas, Ecore and so on, not giving the LGPL bits as BSD. My company also contributed and won't change. I believe Samsung wouldn't change either. Some companies like INdT did that and are not tracking the project, requesting them to look at it, go to lawyers and change... won't happen as well :-) > EFL was BSD before little bits and pieces of LGPL got added. There > was a big debate when eina under LGPL was added, and no one changed > their mind. Instead we end up with this, no one was asked coz as you > said twice, that would have required actual approval. Much easier to > just introduce a small dose of the virus and let it do it's work. It was quite on purpose to keep EFL free software. Some companies were using that without giving back... which is bad overall. >> As for LGPL, your understanding is wrong. It's not LGPL fault, it's >> BSD that allows that. LGPL just requires, if BSD didn't allow they >> would conflict. > > Now that's just crazy talk. BSD licence did not force LGPL to add > virus clauses to the LGPL licence. You certainly can't blame BSD for > a decision made by the FSF. I'd kindly ask you to review the licenses and their terms. BSD says nothing other than you must retain its copyright when you distribute its source code. It's fully a subset of LGPL, as so LGPL is more restrictive, extending with more clauses. There is nothing related to virus other than FUD. The BSD license says you can do whatever you want to the code if you keep the copyright and notice. The LGPL says you must do that and always give away the source (with bit more). You can choose to use it or not, there is no virus in that. Can you choose to get the flu or not? I never saw a flu virus on the street "I'm here, if you want to get infected by me drink this glass of water". > Oh well, EFL is slowly moving away from the ideals that attracted me to > it in the first place, and nothing I can do about that. Some of these > changes mean I can no longer whole heartedly recommend EFL as a great > base for most projects. I'll just have to be extra careful to not get > any GPL virus on my BSD projects that I would prefer to use EFL for. > For commercial work, I'll now have to deal with explaining GPL to > clients and hope that does not scare them off. EFL is still great, it's > just a little less great now, and still better than the other crap. It's LGPL not GPL (unless you do PS3). Other than that, I run a business for 5 years now and the company grew quite a lot, around 30 people. This was only possible due LGPL, if it was BSD this wouldn't happen with EFL. LGPL is good for foundation libraries you build on top. Particularly if you are a small business. - It guarantees that if your customer used LGPL, you can continue someone's else work. The previous supplier must provide you with that source == new customers; - It guarantees that if you change some LGPL for your customer X and he publishes the binaries, he must do the source. That you can use for other customer, LEGALLY saving you some work/redo. Optimize Evas for one customer, the other will get a faster evas as well. - Some companies fear/don't understand FOSS communities and will pay small business that do to work on that. - Your customer can be happy as he would be getting goods on both cases above: if you're bad supplier he can replace you, he may get more stuff for free. Regards, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . licenses
On Thu, Jan 17, 2013 at 1:19 AM, David Seikel wrote: [...] >> >> > > > +NOTE: If linked together, the result will be LGPL (or GPL is >> >> > > > Escape is +used) due that license characteristics. >> >> > > >> >> > > Hmmm, guess that means the BSD licences are useless, since >> >> > > it's all gonna be linked together anyway, and thus GPL >> >> > > contaminated. >> >> > >> >> > >> >> > That is right. For all purposes consider EFL = LGPL. We just >> >> > didn't change the license as it would require approvals. But >> >> > effectively it's all LGPL. >> >> >> >> I'll note that "effectively" changing it all to LGPL did not >> >> require approvals. >> > >> > Well, the resulting license is different. Indeed it will be LGPL. >> > But say you take Evas and remove eina dep, you could use that as >> > BSD. > > You say that like it would be an easy thing to remove the eina > dependency from evas. Note that there is nothing wrong with the eina > code, it's generally quite good code. it's not easy... but who said it should be? One wants to NOT comply with a license, so one does some work :-P >> Also writing Evas engine/loader/saver and Ecore_Evas/Ecore will be >> under BSD letting you write your own backend that doesn't require to >> be upstream, because we don't really care about all the crazy fb API >> in that world. Can be useful in some embedded case. > > In my embedded case the only reason I can tell the client that he does > not have to worry about crazy virus licences is cause he's not > distributing binaries to other peolpe, they all remain under his > control. This so freaking complex that it's better for you not not guarantee anything. I've been told that even IPC (dbus, sockets) may be considered "tainted" if you do in the sole purpose to circumvent some license and the copyright holder wants to go after you. > The debate will rage on once more. The people that thought they where > licensing their code under BSD will mewl ineffectively about their > rights being taken away. The GPL people will smugly and effectively say > "ner ner ner, nothing you can do about it now". In the end the debate > will be as ineffective as the BSD licence, the only likely result might > be the loss of some developers. This debate happened when we merged eina in 2008. It was on purpose made LGPL, with Cedric, raster and I being the supporters (among others). Some people left, but project still stand. As for "licensing their code under BSD will mewl ineffectively about their rights being taken away"... it's complete non-sense. Their rights weren't taken away, they explicitly gave their agreement by using the license: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. the second clause doesn't matter as we just distribute in source. The source retains the copyright and conditions and disclaimer... so the license is being fulfilled. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . licenses
On Thu, Jan 17, 2013 at 1:03 AM, Carsten Haitzler wrote: > On Wed, 16 Jan 2013 22:50:08 -0200 Gustavo Sverzut Barbieri > said: > >> On Wednesday, January 16, 2013, David Seikel wrote: >> >> > On Wed, 16 Jan 2013 13:48:14 -0800 "Enlightenment SVN" >> > > wrote: >> > >> > > Log: >> > > add missing licenses references, fix copyright, add link result >> > > notice. >> > > >> > > Author: barbieri >> > > Date: 2013-01-16 13:48:14 -0800 (Wed, 16 Jan 2013) >> > > New Revision: 82911 >> > > Trac: http://trac.enlightenment.org/e/changeset/82911 >> > > >> > > Modified: >> > > trunk/efl/COPYING trunk/efl/licenses/COPYING.BSD >> > > trunk/efl/licenses/COPYING.LGPL >> > > >> > > Modified: trunk/efl/COPYING >> > > === >> > > --- trunk/efl/COPYING 2013-01-16 21:47:37 UTC (rev 82910) >> > > +++ trunk/efl/COPYING 2013-01-16 21:48:14 UTC (rev 82911) >> > > @@ -1,11 +1,23 @@ >> > > -EFL comes with several licences. Listed are the library/probject >> > > +EFL comes with several licences. Listed are the library/project >> > > name and the license file covering it. >> > > >> > > evil:licenses/COPYING.BSD >> > > -escape: licenses/COPYING.GPL >> > > +escape: licenses/COPYING.GPL (used in PlayStation native) >> > > +eina:licenses/COPYING.LGPL >> > > eet: licenses/COPYING.BSD >> > > -eina:licenses/COPYING.LGPL >> > > eo: licenses/COPYING.BSD >> > > evas:licenses/COPYING.BSD >> > > +embryo: licenses/COPYING.SMALL >> > > ecore: licenses/COPYING.BSD >> > > -embryo: licenses/COPYING.SMALL >> > > +eio: licenses/COPYING.LGPL >> > > +edbus: licenses/COPYING.LGPL >> > > +efreet: licenses/COPYING.BSD >> > > +eeze:licenses/COPYING.BSD >> > > +ephysics:licenses/COPYING.BSD >> > > +edje:licenses/COPYING.BSD >> > > +edje/epp:licenses/COPYING.GPL (separate binary/executable) >> > > +emotion: licenses/COPYING.BSD >> > > +ethumb: licenses/COPYING.LGPL >> > > + >> > > +NOTE: If linked together, the result will be LGPL (or GPL is Escape >> > > is +used) due that license characteristics. >> > >> > Hmmm, guess that means the BSD licences are useless, since it's all >> > gonna be linked together anyway, and thus GPL contaminated. >> >> >> That is right. For all purposes consider EFL = LGPL. We just didn't change >> the license as it would require approvals. But effectively it's all LGPL. > > incorrect. only if we make a single libefl.so is this the case. The on-disk .so files are not, but as soon as they are dynamically linked in the application they do that. Unfortunately I had to learn that with some lawyers :-P -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk/efl: . src
Replying both in one email: On Thu, Jan 17, 2013 at 7:50 AM, Tom Hacohen wrote: > On 17/01/13 06:43, Cedric BAIL wrote: >> On Wed, Jan 16, 2013 at 5:51 AM, Enlightenment SVN >> wrote: >>> Log: >>> efl: use autotools testsuite for running tests >>> >>>Instead of just making our own "check-local" and calling the binaries >>>ourselves, just append them into "TESTS" variable. Then they run after >>>all check_PROGRAMS are compiled. >>> >>>The reasons for changing are: >>> 1) If we change the test and call "make check" the test is not >>> compiled again -- and the only way to compile it is to "make clean". >>> 2) There's no need to reinvent the wheel here. >>> >>>With a recent version of Automake, the test output is redirected to log >>>files. This is good but unexpected for whom was used to the previous >>>way. So, be warned. >> >> Where is that log file ? name_suite.log in their directory, with an unified version in src/. > We want it to print to stdout/err because we need it to show in > buildbot... Could you at least add a "cat" afterwards to dump the log > files so they'll show in buildbot or something? Unless I didn't get you > right... Seems it's working fine: http://build.enlightenment.fr/builders/quick-linux/builds/3086/steps/test/logs/stdio -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Sync vs Async: numbers!
On Thu, Jan 17, 2013 at 1:11 PM, Leandro Pereira wrote: > Hey, > > Here are some numbers that show that the async renderer is actually > saving us time. These numbers can be obtained by yourself, by building > Evas with EVAS_RENDER_DEBUG_TIMING defined and setting/unsetting the > ECORE_EVAS_FORCE_SYNC_RENDER environment variable. > > This number is the measure, in ms, of the time spent during the Evas > rendering function. The average value is calculated every 100 calls. > > One can clearly see that the asynchronous renderer frees up a lot of > time in the main thread, in some cases using 10% of the time the > synchronous renderer needed: > > ⮀ export ECORE_EVAS_FORCE_SYNC_RENDER=1 [...] > *** sync render: avg 1.754684ms min 0.486945ms max 3.843055ms > *** sync render: avg 1.853960ms min 0.92ms max 7.829068ms > *** sync render: avg 2.597078ms min 0.549895ms max 25.936982ms [...] > ⮀ unset ECORE_EVAS_FORCE_SYNC_RENDER > *** async render: avg 0.356258ms min 0.113084ms max 1.723979ms > *** async render: avg 0.357304ms min 0.174066ms max 1.776023ms > *** async render: avg 0.339344ms min 0.165109ms max 1.570926ms Yes, that's the kind of gain we expected from async render. As there is no magic, you end doing MORE work to delegate to the thread, but you have more predictable time spend on the main thread (min closer to max, average is more constant). As the async render will "drop" frames per design (it will keep queue full, but will not stop to render all requested frames, effectively dropping some render() calls at no visual loss), your application will always behave more smoothly, being able to interact with user input more often. As for the predictable part, it's still not fixed in time, but we can determine the time it will spend on the main thread - Async: - Main Thread: depends on number of objects - Render Thread: depends on number of objects AND output size - Sync: main thread depends on number of objects AND output size Test hint: one can induce slowness by running with valgrind. The async version behaves more smoothly than the other :-) Win! \o/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Thu, Jan 17, 2013 at 12:15 PM, Cedric BAIL wrote: > On Thu, Jan 17, 2013 at 10:34 PM, Gustavo Sverzut Barbieri > wrote: >> On Thursday, January 17, 2013, Cedric BAIL wrote: >>> On Thu, Jan 17, 2013 at 9:37 PM, Gustavo Sverzut Barbieri >>> > wrote: >>> > On Thursday, January 17, 2013, Cedric BAIL wrote: >>> >> On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri >>> >> > wrote: >>> >> > On Thursday, January 17, 2013, Enlightenment SVN wrote: >>> >> >> Log: >>> >> >> efl: stupid micro optimization. >>> >> >> >>> >> >> This single test accounted for 1% of my terminology benchmark. >>> >> >> I am considering moving evas_string_char_next_get and >>> >> >> eina_unicode_utf8_get_next to become inline as their function >>> >> >> entry/exit point account for 3% of the same benchmark. >>> >> >> >>> >> >> The biggest win would be to get rid of the memcpy >>> _termpty_text_copy >>> >> >> that account for 16%. >>> >> >> >>> >> >> In the micro optimization part, we also still do to much malloc >>> >> >> in font_draw_prepare as we don't recycle the array there and >>> account >>> >> >> for 3% of the benchmark in malloc/free there. In the same ballpark >>> >> >> _text_save_top account for 2% of the time in malloc/free. >>> >> >> >>> >> >> In that same benchmark, evas_object_textgrid_render account for 5% >>> >> >> where 4% of its time is spend in evas_common_font_draw_prepare. At >>> >> this >>> >> >> point I am not sure that rewriting textgrid is gona help us at >>> all. We >>> >> >> will win almost as much by just inlining the get_next things in >>> evas >>> >> >> and eina for a minute of development time. >>> >> > >>> >> > It's a bit naive to think so, because you'd be able to change the >>> >> algorithm >>> >> > and avoid conversions. All in all you could just give engine the same >>> >> array >>> >> > that terminology fills (cell row array), together with region and >>> context >>> >> > (clipper, cutouts) and glyph bitmap. >>> >> > >>> >> > Particularly the glyph bitmap could be optimized as its an int hash, >>> but >>> >> we >>> >> > know A-Za-z0-9 ate hot, we could have ASCII printable range in an >>> array >>> >> > while everything else goes to a hash >>> >> >>> >> Time spend in evas_common_font_draw 4%. Time spend in >>> >> evas_object_textgrid_*: > 2%. >>> >> Time spend in _cb_fb_read : 82% with evas_string_char_next_get being >>> >> 15% and memcpy 18%. >>> >> >>> >> I don't see how optimizing textgrid is going to change this number at >>> all. >>> > >>> > You'd not be doing these at all. That's why/how. >>> >>> What do you mean by "these" ? I am going to redo the benchmark with >>> perf on another computer to see if there is something else. >> >> >> These calls. If you do the way I imagine you give the screen (array of >> cells) to the render much like the way you give pixels to image. There is >> no need to call a bunch of things, like no need to create the text props >> and such. All you need is the cell info (palette index and attributes), the >> palette contents and a way to convert Unicode -> bitmap. > > All the cost of this 4% goes into the blitting, that you can't win. So > you are basically going after a 2% improvement, that you can maybe > reduce a little but not much as we don't create the text props at all > in more than 99% of the case and the text props is a mapping from > unicode to bitmap that are recycled very often. I really think you are > focusing on the wrong thing here. You can allow engine to cache not only the glyphs, but the cells. (with bg/font colors, translating into pure image blit). Text grid is pretty cache friendly for one alphabet, and for terminology that will definitely hit ASCII as user data may be outside it, but compile output, commands and similar are all ASCII :-) You can have an array of printable elements and access them in O(1), no translation. And if you do such, the grid contents needs no special handling. It will be like an image, you can think about an image with different colorspace :-) as for the _cb_fd_read(), indeed it's outside of the concept of textgrid... and looking at it it's pretty obvious that should optimizations could be applied, simply by changing how it converts the chars to unicode, then handle it to handle_buf just to grow its buffer and copy. The (n == 0) block can also be simplified and optimized at the same time :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _
Re: [E-devel] need advice for refactorying elc_multibuttonentry
+1 here :) Multimuttonentry should have been reviewed correctly since the beginning. Thanks for the refactoring but you should NOT: 1) break C API. (you confirmed) 2) break signals. (you confirmed) 3) break theme API. Existing theme should work. 4) break any apps which were using multibuttonentry already. There should be no application change. 5) create performance degression. I think you don't need backport for elementary-1.7. This is not a simple bug fix. This is REFACTORING. But you should adopt EO as latest elementary codes do. Can you send your multibuttonentry patch that we can test with? Thanks. Daniel Juyung Seo (SeoZ) On Thu, Jan 17, 2013 at 10:41 PM, Gustavo Lima Chaves wrote: > * Sohyun Kim [2013-01-17 14:48:08 +0900]: > > Hi, Sohyun. > > I think you might have broken theme API. If you kept the C API, > though, I happy to ignore the other borkage, because this widget's > code really sucks big time, as of now. You have my blessing to replace it. > >> Hello, this is Sohyun Kim. >> I need your advice for refactorying the elc_multibuttonentry widget. >> >> When we used it in the tizen project, we found several fatal problems, and >> they were very complex to fix. >> Because multibuttonentry had structural weakness, as I fixed bugs, it >> increased the complexity. >> >> Multibuttonentry had several big issues. >> * resizing from box pack/unpack was occured frequently >> (all items were unpacked and re-packed whenever it had focus and lost >> focus, widget edje was clicked, even though on box resizing callback) >> * focus >>- focus was frequently changed between items. (from multibuttonentry -> >> entry -> button -> entry..) >>- button item kept selected state and emited signal although >> multibuttonentry didn't have focus. >>- it handled input panel state manually, but the panel was not shown >> sometimes when entry got focus. >> >> I think bug fixing based on the current code, it makes code more complex, >> So I want to make the widget new, more simply. >> >> * make use-cases simple >>- when multibuttonentry gets focus, entry gets focus always if it is >> editable. After that, when button item is clicked, the button gets focus. >>- button selected state is available when multibuttonentry has focus. >> * only when items should be unpacking or packing, it will be occured. >> * handling focus and input panel state will be dealt with object events. >> (not manually) >> >> Actually, I've made the new multibuttonentry widget recently, and it is >> verified with tizen project internally. >> I should have made it after discussing with you guys, but we had urgent and >> long lasted issues, so I did it. >> I feel sorry for that, but I want to contribute it with you guys. >> >> I didn't change apis and signals at all and the changes cover all scenario. >> After reviewing all new codes, changing the codes with old one is the best >> and simplest way to contribute for me, >> but if patches should be divided to multiple by functions, I will follow it. >> >> Please give me any advice. >> Or if you have any opinions for the refactorying, please feel free to tell >> me. >> >> Regards, Sohyun. >> -- >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122712 >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- > Gustavo Lima Chaves > Senior Developer @ ProFUSION Embedded Systems > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo
[E-devel] Evas Sync vs Async: numbers!
Hey, Here are some numbers that show that the async renderer is actually saving us time. These numbers can be obtained by yourself, by building Evas with EVAS_RENDER_DEBUG_TIMING defined and setting/unsetting the ECORE_EVAS_FORCE_SYNC_RENDER environment variable. This number is the measure, in ms, of the time spent during the Evas rendering function. The average value is calculated every 100 calls. One can clearly see that the asynchronous renderer frees up a lot of time in the main thread, in some cases using 10% of the time the synchronous renderer needed: ⮀ export ECORE_EVAS_FORCE_SYNC_RENDER=1 ⮀ elementary_test Animation *** sync render: avg 2.978395ms min 0.947041ms max 30.379951ms *** sync render: avg 1.957078ms min 0.474035ms max 4.538885ms *** sync render: avg 1.872930ms min 0.760945ms max 4.978016ms *** sync render: avg 1.724530ms min 0.906000ms max 3.591879ms *** sync render: avg 1.902350ms min 0.627998ms max 14.931986ms *** sync render: avg 1.692699ms min 0.940035ms max 3.616943ms *** sync render: avg 1.754144ms min 0.834012ms max 5.288051ms *** sync render: avg 1.699393ms min 0.899117ms max 3.489920ms *** sync render: avg 1.887736ms min 0.519943ms max 9.911051ms *** sync render: avg 1.775922ms min 0.989104ms max 3.373019ms *** sync render: avg 1.712771ms min 0.714912ms max 4.344922ms *** sync render: avg 1.752106ms min 0.918924ms max 4.158897ms *** sync render: avg 1.754684ms min 0.486945ms max 3.843055ms *** sync render: avg 1.853960ms min 0.92ms max 7.829068ms *** sync render: avg 2.597078ms min 0.549895ms max 25.936982ms ^C ⮀ unset ECORE_EVAS_FORCE_SYNC_RENDER ⮀ elementary_test Animation *** async render: avg 1.705852ms min 0.105016ms max 32.549012ms *** async render: avg 0.687507ms min 0.153924ms max 1.679043ms *** async render: avg 0.364832ms min 0.146887ms max 1.703969ms *** async render: avg 0.369488ms min 0.175889ms max 1.931037ms *** async render: avg 0.367418ms min 0.151098ms max 2.927121ms *** async render: avg 0.351177ms min 0.156086ms max 1.636885ms *** async render: avg 0.353286ms min 0.163990ms max 1.528031ms *** async render: avg 0.338158ms min 0.126063ms max 1.547922ms *** async render: avg 0.355310ms min 0.168943ms max 1.684109ms *** async render: avg 0.344575ms min 0.149928ms max 1.368967ms *** async render: avg 0.351807ms min 0.101041ms max 1.538111ms *** async render: avg 0.356258ms min 0.113084ms max 1.723979ms *** async render: avg 0.357304ms min 0.174066ms max 1.776023ms *** async render: avg 0.339344ms min 0.165109ms max 1.570926ms ^C Less dramatic but still interesting results are visible with Terminology running a redraw-intensive program such as the `aafire` demo from aalib: ⮀ unset ECORE_EVAS_FORCE_SYNC_RENDER ⮀ terminology -e aafire -driver curses *** async render: avg 1.949910ms min 0.320094ms max 6.811932ms *** async render: avg 2.314617ms min 0.566074ms max 8.457115ms *** async render: avg 2.440161ms min 0.544033ms max 8.315109ms *** async render: avg 2.503508ms min 0.610092ms max 8.186047ms *** async render: avg 2.339103ms min 0.586006ms max 9.791975ms *** async render: avg 1.971868ms min 0.570879ms max 9.002959ms *** async render: avg 2.698837ms min 0.558963ms max 11.941055ms *** async render: avg 2.236830ms min 0.541988ms max 11.201896ms ^C ⮀ export ECORE_EVAS_FORCE_SYNC_RENDER=1 ⮀ terminology -e aafire -driver curses *** sync render: avg 4.777478ms min 0.809918ms max 12.482078ms *** sync render: avg 5.043696ms min 2.887004ms max 11.873881ms *** sync render: avg 4.810856ms min 2.514057ms max 11.527033ms *** sync render: avg 4.873759ms min 2.718049ms max 9.166908ms *** sync render: avg 5.406739ms min 2.945019ms max 28.283098ms *** sync render: avg 5.224728ms min 2.833047ms max 12.698107ms *** sync render: avg 5.378743ms min 2.787025ms max 13.941910ms *** sync render: avg 4.993303ms min 2.939022ms max 11.360896ms *** sync render: avg 5.065144ms min 2.356000ms max 13.610107ms ^C Cheers, Leandro -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: seoz trunk/devs/seoz
On Thu, Jan 17, 2013 at 7:32 PM, Gustavo Sverzut Barbieri wrote: > On Thursday, January 17, 2013, Enlightenment SVN wrote: > >> Log: >> devs/seoz build.sh: Do not build b0rken exquisite due to ecore-fb. > > > It's not broken, just enable it: > Hello Barbieri > --enable-fb --disable-tslib Oh I missed that :) It works well with those options. Thanks! Daniel Juyung Seo (SeoZ) > > Of course you don't need tslib if your running on a desktop. > > > >> >> Author: seoz >> Date: 2013-01-17 01:02:00 -0800 (Thu, 17 Jan 2013) >> New Revision: 82925 >> Trac: http://trac.enlightenment.org/e/changeset/82925 >> >> Modified: >> trunk/devs/seoz/build.sh >> >> Modified: trunk/devs/seoz/build.sh >> === >> --- trunk/devs/seoz/build.sh2013-01-17 07:21:06 UTC (rev 82924) >> +++ trunk/devs/seoz/build.sh2013-01-17 09:02:00 UTC (rev 82925) >> @@ -32,10 +32,10 @@ >> export BUILD_CPP_BINDINGS="BINDINGS/cxx/eflxx BINDINGS/cxx/einaxx >> BINDINGS/cxx/evasxx BINDINGS/cxx/ecorexx BINDINGS/cxx/edjexx >> BINDINGS/cxx/elementaryxx" >> export BUILD_BINDINGS=$BUILD_PYTHON_BINDINGS" "$BUILD_CPP_BINDINGS" " >> export BUILD_E_MODULES="E-MODULES-EXTRA/comp-scale E-MODULES-EXTRA/elfe >> E-MODULES-EXTRA/engage E-MODULES-EXTRA/forecasts E-MODULES-EXTRA/eweather" >> -export BUILD_ETC="terminology ephysics_tests econnman exactness efx >> PROTO/shotgun editje PROTO/elev8 PROTO/eyelight ephoto edje_viewer >> PROTO/azy elmdentica enlil PROTO/emote emprint clouseau envision ensure >> enjoy exquisite rage PROTO/eyesight" >> +export BUILD_ETC="terminology ephysics_tests econnman exactness efx >> PROTO/shotgun editje PROTO/elev8 PROTO/eyelight ephoto edje_viewer >> PROTO/azy elmdentica enlil PROTO/emote emprint clouseau envision ensure >> enjoy rage PROTO/eyesight" >> export BUILD_EXAMPLE="EXAMPLES/elementary/calculator >> EXAMPLES/elementary/converter EXAMPLES/elementary/phonebook >> EXAMPLES/elementary/sticky-notes" >> export BUILD_GAMES="PROTO/etrophy GAMES/efbb" >> -export BUILD_BROKEN="excessive enki espionnage FORMATTING/ecrustify >> PROTO/enna-explorer E-MODULES-EXTRA/everything-shotgun " >> +export BUILD_BROKEN="excessive enki espionnage FORMATTING/ecrustify >> PROTO/enna-explorer E-MODULES-EXTRA/everything-shotgun exquisite" >> export BUILD_WITH_CMAKE="ecrire" >> >> PWD=`pwd` >> >> >> >> -- >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122712 >> ___ >> 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 > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: acidx IN trunk/efl/src: lib/evas/canvas modules/ecore_evas/engines/x
On Thu, Jan 17, 2013 at 11:31 PM, Enlightenment SVN
wrote:
> Log:
> evas_render: Measure time spent while rendering in sync and async modes
You should use an eina_counter it would be more precise and later we
could bench it on other OS to.
> Author: acidx
> Date: 2013-01-17 06:31:34 -0800 (Thu, 17 Jan 2013)
> New Revision: 82936
> Trac: http://trac.enlightenment.org/e/changeset/82936
>
> Modified:
> trunk/efl/src/lib/evas/canvas/evas_render.c
> trunk/efl/src/modules/ecore_evas/engines/x/ecore_evas_x.c
>
> Modified: trunk/efl/src/lib/evas/canvas/evas_render.c
> ===
> --- trunk/efl/src/lib/evas/canvas/evas_render.c 2013-01-17 13:49:14 UTC (rev
> 82935)
> +++ trunk/efl/src/lib/evas/canvas/evas_render.c 2013-01-17 14:31:34 UTC (rev
> 82936)
> @@ -5,6 +5,10 @@
> #include "evas_cs2_private.h"
> #endif
>
> +#ifdef EVAS_RENDER_DEBUG_TIMING
> +#include
> +#endif
> +
> /* debug rendering
> * NOTE: Define REND_DBG 1 in evas_private.h to enable debugging. Don't
> define
> * it here since the flag is used on other places too. */
> @@ -59,6 +63,59 @@
> static Eina_Bool
> evas_render_updates_internal(Evas *eo_e, unsigned char make_updates,
> unsigned char do_draw, Evas_Render_Done_Cb done_func, void *done_data,
> Evas_Event_Cb updates_func, void *updates_data, Eina_Bool do_async);
>
> +#ifdef EVAS_RENDER_DEBUG_TIMING
> +static double
> +_time_get()
> +{
> + struct timeval tv;
> +
> + gettimeofday(&tv, NULL);
> +
> + return (tv.tv_sec + tv.tv_usec / 100.0) * 1000.0;
> +}
> +
> +struct accumulator {
> + double total, min, max;
> + int samples;
> + const char *what;
> +};
> +
> +static struct accumulator async_accumulator = {
> + .total = 0,
> + .min = 100,
> + .max = 0,
> + .samples = 0,
> + .what = "async render"
> +};
> +static struct accumulator sync_accumulator = {
> + .total = 0,
> + .min = 100,
> + .max = 0,
> + .samples = 0,
> + .what = "sync render"
> +};
> +
> +static void
> +_accumulate_time(double before, struct accumulator *acc)
> +{
> + double diff = _time_get() - before;
> +
> + acc->total += diff;
> + if (diff > acc->max) acc->max = diff;
> + if (diff < acc->min) acc->min = diff;
> +
> + acc->samples++;
> + if (acc->samples % 100 == 0)
> + {
> +fprintf(stderr, "*** %s: avg %fms min %fms max %fms\n",
> +acc->what, acc->total / 100.0, acc->min, acc->max);
> +acc->total = 0.0;
> +acc->max = 0.0;
> +acc->min = 100;
> + }
> +}
> +#endif
> +
> EAPI void
> evas_damage_rectangle_add(Evas *eo_e, int x, int y, int w, int h)
> {
> @@ -1361,6 +1418,9 @@
> int redraw_all = 0;
> Eina_Bool haveup = 0;
> Evas_Render_Mode render_mode = EVAS_RENDER_MODE_UNDEF;
> +#ifdef EVAS_RENDER_DEBUG_TIMING
> + double start_time = _time_get();
> +#endif
>
> MAGIC_CHECK(eo_e, Evas, MAGIC_EVAS);
> return EINA_FALSE;
> @@ -1852,6 +1912,10 @@
>
> RD("---]\n");
>
> +#ifdef EVAS_RENDER_DEBUG_TIMING
> + _accumulate_time(start_time, do_async ? &async_accumulator :
> &sync_accumulator);
> +#endif
> +
> return EINA_TRUE;
> }
>
>
> Modified: trunk/efl/src/modules/ecore_evas/engines/x/ecore_evas_x.c
> ===
> --- trunk/efl/src/modules/ecore_evas/engines/x/ecore_evas_x.c 2013-01-17
> 13:49:14 UTC (rev 82935)
> +++ trunk/efl/src/modules/ecore_evas/engines/x/ecore_evas_x.c 2013-01-17
> 14:31:34 UTC (rev 82936)
> @@ -3178,8 +3178,12 @@
> ee->prop.request_pos = 0;
> ee->prop.sticky = 0;
> edata->state.sticky = 0;
> - ee->can_async_render = 1;
>
> + if (getenv("ECORE_EVAS_FORCE_SYNC_RENDER"))
> + ee->can_async_render = 0;
> + else
> + ee->can_async_render = 1;
> +
> /* init evas here */
> ee->evas = evas_new();
> evas_event_callback_add(ee->evas, EVAS_CALLBACK_RENDER_FLUSH_PRE,
>
>
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> ___
> enlightenment-svn mailing list
> enlightenment-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
>
--
Cedric BAIL
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Thu, Jan 17, 2013 at 10:34 PM, Gustavo Sverzut Barbieri wrote: > On Thursday, January 17, 2013, Cedric BAIL wrote: >> On Thu, Jan 17, 2013 at 9:37 PM, Gustavo Sverzut Barbieri >> > wrote: >> > On Thursday, January 17, 2013, Cedric BAIL wrote: >> >> On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri >> >> > wrote: >> >> > On Thursday, January 17, 2013, Enlightenment SVN wrote: >> >> >> Log: >> >> >> efl: stupid micro optimization. >> >> >> >> >> >> This single test accounted for 1% of my terminology benchmark. >> >> >> I am considering moving evas_string_char_next_get and >> >> >> eina_unicode_utf8_get_next to become inline as their function >> >> >> entry/exit point account for 3% of the same benchmark. >> >> >> >> >> >> The biggest win would be to get rid of the memcpy >> _termpty_text_copy >> >> >> that account for 16%. >> >> >> >> >> >> In the micro optimization part, we also still do to much malloc >> >> >> in font_draw_prepare as we don't recycle the array there and >> account >> >> >> for 3% of the benchmark in malloc/free there. In the same ballpark >> >> >> _text_save_top account for 2% of the time in malloc/free. >> >> >> >> >> >> In that same benchmark, evas_object_textgrid_render account for 5% >> >> >> where 4% of its time is spend in evas_common_font_draw_prepare. At >> >> this >> >> >> point I am not sure that rewriting textgrid is gona help us at >> all. We >> >> >> will win almost as much by just inlining the get_next things in >> evas >> >> >> and eina for a minute of development time. >> >> > >> >> > It's a bit naive to think so, because you'd be able to change the >> >> algorithm >> >> > and avoid conversions. All in all you could just give engine the same >> >> array >> >> > that terminology fills (cell row array), together with region and >> context >> >> > (clipper, cutouts) and glyph bitmap. >> >> > >> >> > Particularly the glyph bitmap could be optimized as its an int hash, >> but >> >> we >> >> > know A-Za-z0-9 ate hot, we could have ASCII printable range in an >> array >> >> > while everything else goes to a hash >> >> >> >> Time spend in evas_common_font_draw 4%. Time spend in >> >> evas_object_textgrid_*: > 2%. >> >> Time spend in _cb_fb_read : 82% with evas_string_char_next_get being >> >> 15% and memcpy 18%. >> >> >> >> I don't see how optimizing textgrid is going to change this number at >> all. >> > >> > You'd not be doing these at all. That's why/how. >> >> What do you mean by "these" ? I am going to redo the benchmark with >> perf on another computer to see if there is something else. > > > These calls. If you do the way I imagine you give the screen (array of > cells) to the render much like the way you give pixels to image. There is > no need to call a bunch of things, like no need to create the text props > and such. All you need is the cell info (palette index and attributes), the > palette contents and a way to convert Unicode -> bitmap. All the cost of this 4% goes into the blitting, that you can't win. So you are basically going after a 2% improvement, that you can maybe reduce a little but not much as we don't create the text props at all in more than 99% of the case and the text props is a mapping from unicode to bitmap that are recycled very often. I really think you are focusing on the wrong thing here. -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: morlenxus trunk/E-MODULES-EXTRA/execwatch/src
On Thu, 17 Jan 2013 05:49:15 -0800
"Enlightenment SVN" wrote:
> Log:
> unset pointer, thanks obiwahn
>
> Author: morlenxus
> Date: 2013-01-17 05:49:14 -0800 (Thu, 17 Jan 2013)
> New Revision: 82935
> Trac: http://trac.enlightenment.org/e/changeset/82935
>
> Modified:
> trunk/E-MODULES-EXTRA/execwatch/src/e_mod_main.c
>
> Modified: trunk/E-MODULES-EXTRA/execwatch/src/e_mod_main.c
> ===
> --- trunk/E-MODULES-EXTRA/execwatch/src/e_mod_main.c 2013-01-17 12:15:02 UTC
> (rev 82934)
> +++ trunk/E-MODULES-EXTRA/execwatch/src/e_mod_main.c 2013-01-17 13:49:14 UTC
> (rev 82935)
> @@ -241,7 +241,10 @@
>
> if (!inst) return;
> if (inst->status_exe_result)
> - E_FREE(inst->status_exe_result);
> + {
> +E_FREE(inst->status_exe_result);
> + inst->status_exe_result = NULL;
> + }
> if (inst->read && inst->read->lines)
> {
> Ecore_Exe_Event_Data_Line *lines;
>
>
this commit has no functional change whatsoever
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] need advice for refactorying elc_multibuttonentry
* Sohyun Kim [2013-01-17 14:48:08 +0900]: Hi, Sohyun. I think you might have broken theme API. If you kept the C API, though, I happy to ignore the other borkage, because this widget's code really sucks big time, as of now. You have my blessing to replace it. > Hello, this is Sohyun Kim. > I need your advice for refactorying the elc_multibuttonentry widget. > > When we used it in the tizen project, we found several fatal problems, and > they were very complex to fix. > Because multibuttonentry had structural weakness, as I fixed bugs, it > increased the complexity. > > Multibuttonentry had several big issues. > * resizing from box pack/unpack was occured frequently > (all items were unpacked and re-packed whenever it had focus and lost > focus, widget edje was clicked, even though on box resizing callback) > * focus >- focus was frequently changed between items. (from multibuttonentry -> > entry -> button -> entry..) >- button item kept selected state and emited signal although > multibuttonentry didn't have focus. >- it handled input panel state manually, but the panel was not shown > sometimes when entry got focus. > > I think bug fixing based on the current code, it makes code more complex, > So I want to make the widget new, more simply. > > * make use-cases simple >- when multibuttonentry gets focus, entry gets focus always if it is > editable. After that, when button item is clicked, the button gets focus. >- button selected state is available when multibuttonentry has focus. > * only when items should be unpacking or packing, it will be occured. > * handling focus and input panel state will be dealt with object events. > (not manually) > > Actually, I've made the new multibuttonentry widget recently, and it is > verified with tizen project internally. > I should have made it after discussing with you guys, but we had urgent and > long lasted issues, so I did it. > I feel sorry for that, but I want to contribute it with you guys. > > I didn't change apis and signals at all and the changes cover all scenario. > After reviewing all new codes, changing the codes with old one is the best > and simplest way to contribute for me, > but if patches should be divided to multiple by functions, I will follow it. > > Please give me any advice. > Or if you have any opinions for the refactorying, please feel free to tell > me. > > Regards, Sohyun. > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Lima Chaves Senior Developer @ ProFUSION Embedded Systems -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Thursday, January 17, 2013, Cedric BAIL wrote: > On Thu, Jan 17, 2013 at 9:37 PM, Gustavo Sverzut Barbieri > > wrote: > > On Thursday, January 17, 2013, Cedric BAIL wrote: > >> On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri > >> > wrote: > >> > On Thursday, January 17, 2013, Enlightenment SVN wrote: > >> >> Log: > >> >> efl: stupid micro optimization. > >> >> > >> >> This single test accounted for 1% of my terminology benchmark. > >> >> I am considering moving evas_string_char_next_get and > >> >> eina_unicode_utf8_get_next to become inline as their function > >> >> entry/exit point account for 3% of the same benchmark. > >> >> > >> >> The biggest win would be to get rid of the memcpy > _termpty_text_copy > >> >> that account for 16%. > >> >> > >> >> In the micro optimization part, we also still do to much malloc > >> >> in font_draw_prepare as we don't recycle the array there and > account > >> >> for 3% of the benchmark in malloc/free there. In the same ballpark > >> >> _text_save_top account for 2% of the time in malloc/free. > >> >> > >> >> In that same benchmark, evas_object_textgrid_render account for 5% > >> >> where 4% of its time is spend in evas_common_font_draw_prepare. At > >> this > >> >> point I am not sure that rewriting textgrid is gona help us at > all. We > >> >> will win almost as much by just inlining the get_next things in > evas > >> >> and eina for a minute of development time. > >> > > >> > It's a bit naive to think so, because you'd be able to change the > >> algorithm > >> > and avoid conversions. All in all you could just give engine the same > >> array > >> > that terminology fills (cell row array), together with region and > context > >> > (clipper, cutouts) and glyph bitmap. > >> > > >> > Particularly the glyph bitmap could be optimized as its an int hash, > but > >> we > >> > know A-Za-z0-9 ate hot, we could have ASCII printable range in an > array > >> > while everything else goes to a hash > >> > >> Time spend in evas_common_font_draw 4%. Time spend in > >> evas_object_textgrid_*: > 2%. > >> Time spend in _cb_fb_read : 82% with evas_string_char_next_get being > >> 15% and memcpy 18%. > >> > >> I don't see how optimizing textgrid is going to change this number at > all. > > > > You'd not be doing these at all. That's why/how. > > What do you mean by "these" ? I am going to redo the benchmark with > perf on another computer to see if there is something else. These calls. If you do the way I imagine you give the screen (array of cells) to the render much like the way you give pixels to image. There is no need to call a bunch of things, like no need to create the text props and such. All you need is the cell info (palette index and attributes), the palette contents and a way to convert Unicode -> bitmap. > -- > Cedric BAIL > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > 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 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] async render + scalecache.. new segv fun
Hi Raster,
We'll debug this. And yes, it should be scalecache and its pruning.
-- Ulisses
On Thu, Jan 17, 2013 at 9:09 AM, Carsten Haitzler wrote:
> so now.. i get these random "hard to reproduce" crashes with async render. i'm
> certain its scalecache related.
>
> here is what i see now. 1. clipouts and all scalecache decisions are made in
> the "main loop" before async thread. this means the scalecache logic that was
> built for running inline will generate scalecache entries... but it may ALSO
> delete them as it goes (as # of scalecache items per image exceeds the max
> count or cache is full etc.).
>
> normally if scalecache is generated as u render in your rendering thread this
> is no problem as things are generated and freed in a serial way.
>
> but now reading the code the thread commands are pose scalecache generation so
> the scaling is done in mainloop and the already scaled data is kept in the
> scalecache.. and commands to USE that data (and after clipouts) are then run
> async...
>
> and right now my bet is.. after a rummage... that a scalecache image entry is
> freed before the async thread can use it during the normal scalecache
> lifecycle.
>
> scalecache had another cool side-effect. it worked on map/proxy buffers too.
> since everything was serial the scalecache items were generated AFTER the
> rendering to the buffer that was the source of the scalecache... right now i
> smell that this would be broken too - i don't have a test case, but reading it
> i smell this is now *bleh*. (ie scalecahce entries are generated from the src
> buffer BEFORE the buffer has been filled with updated data).
>
> as i see it - it requires the scalecache data generation to be done IN the
> async thread, not outside of it before queueing. creation of new scalecache
> items (ore deletion etc.) ne4eds to happen there. :/
>
> backtrace here:
>
> bt:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb74d0b40 (LWP 2668)]
> _op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
> at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
> 11 MOV_P2R(*s, mm2, mm0)
> (gdb) bt
> #0 _op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
> at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
> #1 0x0028c86d in evas_common_scale_rgba_sample_draw (src=0xa349540,
> dst=0xa4dfd08, dst_clip_x=59, dst_clip_y=0, dst_clip_w=3, dst_clip_h=29,
> mul_col=4294967295, render_op=0, src_region_x=,
> src_region_y=, src_region_w=3, src_region_h=995,
> dst_region_x=, dst_region_y=,
> dst_region_w=3, dst_region_h=995)
> at lib/evas/common/evas_scale_sample.c:209
> #2 0x002a0f55 in _draw_thread_image_draw (data=0xa2fae00)
> at modules/evas/engines/software_generic/evas_engine.c:1180
> #3 0x00293f03 in evas_thread_worker_func (data=0x0, thread=3075279680)
> at lib/evas/common/evas_thread_render.c:107
> #4 0x00f948cc in _eina_internal_call (context=0xa08b958)
> at lib/eina/eina_thread.c:280
> #5 0x00365d4c in start_thread (arg=0xb74d0b40) at pthread_create.c:308
> #6 0x00c84ace in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
> (gdb) fr 0
> #0 _op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
> at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
> 11 MOV_P2R(*s, mm2, mm0)
> (gdb) p s
> $1 = (DATA32 *) 0x2d48
> (gdb) p *s
> Cannot access memory at address 0x2d48
> (gdb) p d
> $2 = (DATA32 *) 0xb50480ec
> (gdb) p *d
> $3 = 4280295456
> (gdb) fr 2
> #2 0x002a0f55 in _draw_thread_image_draw (data=0xa2fae00)
> at modules/evas/engines/software_generic/evas_engine.c:1180
> 1180 (image->image, image->surface,
> (gdb) l
> 1175image->mul_col, image->render_op,
> 1176image->src.x, image->src.y, image->src.w, image->src.h,
> 1177image->dst.x, image->dst.y, image->dst.w, image->dst.h);
> 1178 else
> 1179 evas_common_scale_rgba_sample_draw
> 1180 (image->image, image->surface,
> 1181image->clip.x, image->clip.y, image->clip.w, image->clip.h,
> 1182image->mul_col, image->render_op,
> 1183image->src.x, image->src.y, image->src.w, image->src.h,
> 1184image->dst.x, image->dst.y, image->dst.w, image->dst.h);
> (gdb) p *image
> $4 = {surface = 0xa4dfd08, image = 0xa349540, src = {x = 0, y = 0, w = 3,
> h = 995}, dst = {x = 59, y = -966, w = 3, h = 995}, clip = {x = 59, y = 0,
> w = 3, h = 29}, mul_col = 4294967295, render_op = 0, smooth = 0}
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
--
Ulisses Furquim
ProFUSION embedded systems
http://profusion.mobi
Mobile: +55 19 9250 0942
Skype: ulissesffs
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, C
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Thu, Jan 17, 2013 at 9:37 PM, Gustavo Sverzut Barbieri wrote: > On Thursday, January 17, 2013, Cedric BAIL wrote: >> On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri >> > wrote: >> > On Thursday, January 17, 2013, Enlightenment SVN wrote: >> >> Log: >> >> efl: stupid micro optimization. >> >> >> >> This single test accounted for 1% of my terminology benchmark. >> >> I am considering moving evas_string_char_next_get and >> >> eina_unicode_utf8_get_next to become inline as their function >> >> entry/exit point account for 3% of the same benchmark. >> >> >> >> The biggest win would be to get rid of the memcpy _termpty_text_copy >> >> that account for 16%. >> >> >> >> In the micro optimization part, we also still do to much malloc >> >> in font_draw_prepare as we don't recycle the array there and account >> >> for 3% of the benchmark in malloc/free there. In the same ballpark >> >> _text_save_top account for 2% of the time in malloc/free. >> >> >> >> In that same benchmark, evas_object_textgrid_render account for 5% >> >> where 4% of its time is spend in evas_common_font_draw_prepare. At >> this >> >> point I am not sure that rewriting textgrid is gona help us at all. We >> >> will win almost as much by just inlining the get_next things in evas >> >> and eina for a minute of development time. >> > >> > It's a bit naive to think so, because you'd be able to change the >> algorithm >> > and avoid conversions. All in all you could just give engine the same >> array >> > that terminology fills (cell row array), together with region and context >> > (clipper, cutouts) and glyph bitmap. >> > >> > Particularly the glyph bitmap could be optimized as its an int hash, but >> we >> > know A-Za-z0-9 ate hot, we could have ASCII printable range in an array >> > while everything else goes to a hash >> >> Time spend in evas_common_font_draw 4%. Time spend in >> evas_object_textgrid_*: > 2%. >> Time spend in _cb_fb_read : 82% with evas_string_char_next_get being >> 15% and memcpy 18%. >> >> I don't see how optimizing textgrid is going to change this number at all. > > You'd not be doing these at all. That's why/how. What do you mean by "these" ? I am going to redo the benchmark with perf on another computer to see if there is something else. -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Thursday, January 17, 2013, Cedric BAIL wrote: > On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri > > wrote: > > On Thursday, January 17, 2013, Enlightenment SVN wrote: > >> Log: > >> efl: stupid micro optimization. > >> > >> This single test accounted for 1% of my terminology benchmark. > >> I am considering moving evas_string_char_next_get and > >> eina_unicode_utf8_get_next to become inline as their function > >> entry/exit point account for 3% of the same benchmark. > >> > >> The biggest win would be to get rid of the memcpy _termpty_text_copy > >> that account for 16%. > >> > >> In the micro optimization part, we also still do to much malloc > >> in font_draw_prepare as we don't recycle the array there and account > >> for 3% of the benchmark in malloc/free there. In the same ballpark > >> _text_save_top account for 2% of the time in malloc/free. > >> > >> In that same benchmark, evas_object_textgrid_render account for 5% > >> where 4% of its time is spend in evas_common_font_draw_prepare. At > this > >> point I am not sure that rewriting textgrid is gona help us at all. We > >> will win almost as much by just inlining the get_next things in evas > >> and eina for a minute of development time. > > > > It's a bit naive to think so, because you'd be able to change the > algorithm > > and avoid conversions. All in all you could just give engine the same > array > > that terminology fills (cell row array), together with region and context > > (clipper, cutouts) and glyph bitmap. > > > > Particularly the glyph bitmap could be optimized as its an int hash, but > we > > know A-Za-z0-9 ate hot, we could have ASCII printable range in an array > > while everything else goes to a hash > > Time spend in evas_common_font_draw 4%. Time spend in > evas_object_textgrid_*: > 2%. > Time spend in _cb_fb_read : 82% with evas_string_char_next_get being > 15% and memcpy 18%. > > I don't see how optimizing textgrid is going to change this number at all. You'd not be doing these at all. That's why/how. > -- > Cedric BAIL > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > 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 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] git.e.fr divergence
On Thu, 17 Jan 2013 12:25:48 +0100 Bertrand Jacquin wrote: > Hi, > > We've got an issue with SVN import to git from svn.e.org so I had to > rewind tree. Thanks for fixing that. > Thoses of you who use it will have to update locale references to avoid > merge by using: > $ git fetch origin > $ git reset --hard origin/maste > > This only concern main repo (svn.git). > > Sorry for convinience. :) -- Igor -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Thu, Jan 17, 2013 at 7:28 PM, Gustavo Sverzut Barbieri wrote: > On Thursday, January 17, 2013, Enlightenment SVN wrote: >> Log: >> efl: stupid micro optimization. >> >> This single test accounted for 1% of my terminology benchmark. >> I am considering moving evas_string_char_next_get and >> eina_unicode_utf8_get_next to become inline as their function >> entry/exit point account for 3% of the same benchmark. >> >> The biggest win would be to get rid of the memcpy _termpty_text_copy >> that account for 16%. >> >> In the micro optimization part, we also still do to much malloc >> in font_draw_prepare as we don't recycle the array there and account >> for 3% of the benchmark in malloc/free there. In the same ballpark >> _text_save_top account for 2% of the time in malloc/free. >> >> In that same benchmark, evas_object_textgrid_render account for 5% >> where 4% of its time is spend in evas_common_font_draw_prepare. At this >> point I am not sure that rewriting textgrid is gona help us at all. We >> will win almost as much by just inlining the get_next things in evas >> and eina for a minute of development time. > > It's a bit naive to think so, because you'd be able to change the algorithm > and avoid conversions. All in all you could just give engine the same array > that terminology fills (cell row array), together with region and context > (clipper, cutouts) and glyph bitmap. > > Particularly the glyph bitmap could be optimized as its an int hash, but we > know A-Za-z0-9 ate hot, we could have ASCII printable range in an array > while everything else goes to a hash Time spend in evas_common_font_draw 4%. Time spend in evas_object_textgrid_*: > 2%. Time spend in _cb_fb_read : 82% with evas_string_char_next_get being 15% and memcpy 18%. I don't see how optimizing textgrid is going to change this number at all. -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] git.e.fr divergence
Hi, We've got an issue with SVN import to git from svn.e.org so I had to rewind tree. Thoses of you who use it will have to update locale references to avoid merge by using: $ git fetch origin $ git reset --hard origin/maste This only concern main repo (svn.git). Sorry for convinience. Beber -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/efl/m4
On Thursday, January 17, 2013, Cedric BAIL wrote: > On Thu, Jan 17, 2013 at 8:04 PM, Gustavo Sverzut Barbieri > > wrote: > > On Wednesday, January 16, 2013, Cedric BAIL wrote: > > > >> On Thu, Jan 17, 2013 at 6:26 AM, Enlightenment SVN > >> > wrote: > >> > Log: > >> > fix internal library linkage to pull in dependencies. > >> > > >> > some libraries will need to pull more than its own .so, for example > >> > Eina.h includes eina_lock.h that includes eina_inline_lock_posix.x > >> > that will use pthread calls directly from user code. > >> > > >> > This was already listed in eina.pc, but not being present in > >> > USE_EINA_LIBS. > >> > > >> > Author: barbieri > >> > Date: 2013-01-16 13:25:58 -0800 (Wed, 16 Jan 2013) > >> > New Revision: 82909 > >> > Trac: http://trac.enlightenment.org/e/changeset/82909 > >> > > >> > Modified: > >> > trunk/efl/m4/efl.m4 > >> > >> I needed to revert it to still be able to build efl. DEPENDENCIES of > >> Ecore_Evas engine where full of -lm -lrt -lstuff that are not provided > >> by the Makefile and can't be a dependencie. > > > > > > Did you revert this revert, right. Is it fixed now? Was actually just > > gcrypt problem? > > Yes, I just think that disabling gcrypt test sounds suspicious, but I > don't know why it was there in the first place. Neither I do. They were there and I find them strange as gnutls provides PC... I guess we remove it and see what breaks, seems nothing. > -- > Cedric BAIL > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > 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 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] async render + scalecache.. new segv fun
so now.. i get these random "hard to reproduce" crashes with async render. i'm
certain its scalecache related.
here is what i see now. 1. clipouts and all scalecache decisions are made in
the "main loop" before async thread. this means the scalecache logic that was
built for running inline will generate scalecache entries... but it may ALSO
delete them as it goes (as # of scalecache items per image exceeds the max
count or cache is full etc.).
normally if scalecache is generated as u render in your rendering thread this
is no problem as things are generated and freed in a serial way.
but now reading the code the thread commands are pose scalecache generation so
the scaling is done in mainloop and the already scaled data is kept in the
scalecache.. and commands to USE that data (and after clipouts) are then run
async...
and right now my bet is.. after a rummage... that a scalecache image entry is
freed before the async thread can use it during the normal scalecache lifecycle.
scalecache had another cool side-effect. it worked on map/proxy buffers too.
since everything was serial the scalecache items were generated AFTER the
rendering to the buffer that was the source of the scalecache... right now i
smell that this would be broken too - i don't have a test case, but reading it
i smell this is now *bleh*. (ie scalecahce entries are generated from the src
buffer BEFORE the buffer has been filled with updated data).
as i see it - it requires the scalecache data generation to be done IN the
async thread, not outside of it before queueing. creation of new scalecache
items (ore deletion etc.) ne4eds to happen there. :/
backtrace here:
bt:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb74d0b40 (LWP 2668)]
_op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
11 MOV_P2R(*s, mm2, mm0)
(gdb) bt
#0 _op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
#1 0x0028c86d in evas_common_scale_rgba_sample_draw (src=0xa349540,
dst=0xa4dfd08, dst_clip_x=59, dst_clip_y=0, dst_clip_w=3, dst_clip_h=29,
mul_col=4294967295, render_op=0, src_region_x=,
src_region_y=, src_region_w=3, src_region_h=995,
dst_region_x=, dst_region_y=,
dst_region_w=3, dst_region_h=995)
at lib/evas/common/evas_scale_sample.c:209
#2 0x002a0f55 in _draw_thread_image_draw (data=0xa2fae00)
at modules/evas/engines/software_generic/evas_engine.c:1180
#3 0x00293f03 in evas_thread_worker_func (data=0x0, thread=3075279680)
at lib/evas/common/evas_thread_render.c:107
#4 0x00f948cc in _eina_internal_call (context=0xa08b958)
at lib/eina/eina_thread.c:280
#5 0x00365d4c in start_thread (arg=0xb74d0b40) at pthread_create.c:308
#6 0x00c84ace in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) fr 0
#0 _op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
11 MOV_P2R(*s, mm2, mm0)
(gdb) p s
$1 = (DATA32 *) 0x2d48
(gdb) p *s
Cannot access memory at address 0x2d48
(gdb) p d
$2 = (DATA32 *) 0xb50480ec
(gdb) p *d
$3 = 4280295456
(gdb) fr 2
#2 0x002a0f55 in _draw_thread_image_draw (data=0xa2fae00)
at modules/evas/engines/software_generic/evas_engine.c:1180
1180 (image->image, image->surface,
(gdb) l
1175image->mul_col, image->render_op,
1176image->src.x, image->src.y, image->src.w, image->src.h,
1177image->dst.x, image->dst.y, image->dst.w, image->dst.h);
1178 else
1179 evas_common_scale_rgba_sample_draw
1180 (image->image, image->surface,
1181image->clip.x, image->clip.y, image->clip.w, image->clip.h,
1182image->mul_col, image->render_op,
1183image->src.x, image->src.y, image->src.w, image->src.h,
1184image->dst.x, image->dst.y, image->dst.w, image->dst.h);
(gdb) p *image
$4 = {surface = 0xa4dfd08, image = 0xa349540, src = {x = 0, y = 0, w = 3,
h = 995}, dst = {x = 59, y = -966, w = 3, h = 995}, clip = {x = 59, y = 0,
w = 3, h = 29}, mul_col = 4294967295, render_op = 0, smooth = 0}
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/efl/m4
On Thu, Jan 17, 2013 at 8:04 PM, Gustavo Sverzut Barbieri wrote: > On Wednesday, January 16, 2013, Cedric BAIL wrote: > >> On Thu, Jan 17, 2013 at 6:26 AM, Enlightenment SVN >> > wrote: >> > Log: >> > fix internal library linkage to pull in dependencies. >> > >> > some libraries will need to pull more than its own .so, for example >> > Eina.h includes eina_lock.h that includes eina_inline_lock_posix.x >> > that will use pthread calls directly from user code. >> > >> > This was already listed in eina.pc, but not being present in >> > USE_EINA_LIBS. >> > >> > Author: barbieri >> > Date: 2013-01-16 13:25:58 -0800 (Wed, 16 Jan 2013) >> > New Revision: 82909 >> > Trac: http://trac.enlightenment.org/e/changeset/82909 >> > >> > Modified: >> > trunk/efl/m4/efl.m4 >> >> I needed to revert it to still be able to build efl. DEPENDENCIES of >> Ecore_Evas engine where full of -lm -lrt -lstuff that are not provided >> by the Makefile and can't be a dependencie. > > > Did you revert this revert, right. Is it fixed now? Was actually just > gcrypt problem? Yes, I just think that disabling gcrypt test sounds suspicious, but I don't know why it was there in the first place. -- Cedric BAIL -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri trunk/efl/m4
On Wednesday, January 16, 2013, Cedric BAIL wrote: > On Thu, Jan 17, 2013 at 6:26 AM, Enlightenment SVN > > wrote: > > Log: > > fix internal library linkage to pull in dependencies. > > > > some libraries will need to pull more than its own .so, for example > > Eina.h includes eina_lock.h that includes eina_inline_lock_posix.x > > that will use pthread calls directly from user code. > > > > This was already listed in eina.pc, but not being present in > > USE_EINA_LIBS. > > > > Author: barbieri > > Date: 2013-01-16 13:25:58 -0800 (Wed, 16 Jan 2013) > > New Revision: 82909 > > Trac: http://trac.enlightenment.org/e/changeset/82909 > > > > Modified: > > trunk/efl/m4/efl.m4 > > I needed to revert it to still be able to build efl. DEPENDENCIES of > Ecore_Evas engine where full of -lm -lrt -lstuff that are not provided > by the Makefile and can't be a dependencie. Did you revert this revert, right. Is it fixed now? Was actually just gcrypt problem? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict IN trunk/e: . src/modules/battery src/modules/mixer
Well, in trunk we always have notification. You can remove those ifdef. I'm
not sure, but I guess we even have a way to output those to notify-OSD or
shortcut (no DBus) to the notification module.
On Thursday, January 17, 2013, Enlightenment SVN wrote:
> Log:
> e mixer and battery modules: reuse notifications.
>
>
> Author: illogict
> Date: 2013-01-17 02:47:53 -0800 (Thu, 17 Jan 2013)
> New Revision: 82931
> Trac: http://trac.enlightenment.org/e/changeset/82931
>
> Modified:
> trunk/e/ChangeLog trunk/e/NEWS trunk/e/src/modules/battery/e_mod_main.c
> trunk/e/src/modules/mixer/e_mod_main.c
> trunk/e/src/modules/mixer/e_mod_main.h
>
> Modified: trunk/e/ChangeLog
> ===
> --- trunk/e/ChangeLog 2013-01-17 10:29:31 UTC (rev 82930)
> +++ trunk/e/ChangeLog 2013-01-17 10:47:53 UTC (rev 82931)
> @@ -1,3 +1,6 @@
> +2013-01-17 Chidambar Zinnoury (ilLogict)
> + * Mixer and battery modules: reuse notifications.
> +
> 2013-01-16 Brian Miculcy
> * Shelf option 'overlapping' made clearer and disabled when
> window automatic movement on shelf hide isn't set.
>
>
> Modified: trunk/e/NEWS
> ===
> --- trunk/e/NEWS2013-01-17 10:29:31 UTC (rev 82930)
> +++ trunk/e/NEWS2013-01-17 10:47:53 UTC (rev 82931)
> @@ -106,3 +106,4 @@
> * fixed bug where starting with a nonexistent config could cause a
> crash instead of simply restarting
> * fixed window border hide bug where after iconification hides leave
> ghosts
> * fixed bug where backlight settings would try to update dummy
> backlight devices
> +* Reuse notifications for mixer and battery modules.
>
> Modified: trunk/e/src/modules/battery/e_mod_main.c
> ===
> --- trunk/e/src/modules/battery/e_mod_main.c2013-01-17 10:29:31 UTC
> (rev 82930)
> +++ trunk/e/src/modules/battery/e_mod_main.c2013-01-17 10:47:53 UTC
> (rev 82931)
> @@ -33,6 +33,9 @@
> Evas_Object *o_battery;
> Evas_Object *popup_battery;
> E_Gadcon_Popup *warning;
> +#ifdef HAVE_ENOTIFY
> + unsigned int notification_id;
> +#endif
> };
>
> static void _battery_update(int full, int time_left, int time_full,
> Eina_Bool have_battery, Eina_Bool have_power);
> @@ -425,7 +428,17 @@
> inst->popup_battery = NULL;
> }
>
> +#ifdef HAVE_ENOTIFY
> static void
> +_battery_warning_popup_cb(void *data, unsigned int id)
> +{
> + Instance *inst = data;
> +
> + inst->notification_id = id;
> +}
> +#endif
> +
> +static void
> _battery_warning_popup(Instance *inst, int t, double percent)
> {
> Evas *e = NULL;
> @@ -445,7 +458,7 @@
> n.sumary = _("Your battery is low!");
> n.body = _("AC power is recommended.");
> n.timeout = battery_config->alert_timeout * 1000;
> -e_notification_client_send(&n, NULL, NULL);
> +e_notification_client_send(&n, _battery_warning_popup_cb, inst);
> return;
> }
> #endif
>
> Modified: trunk/e/src/modules/mixer/e_mod_main.c
> ===
> --- trunk/e/src/modules/mixer/e_mod_main.c 2013-01-17 10:29:31 UTC
> (rev 82930)
> +++ trunk/e/src/modules/mixer/e_mod_main.c 2013-01-17 10:47:53 UTC
> (rev 82931)
> @@ -35,9 +35,19 @@
> static void _mixer_actions_unregister(E_Mixer_Module_Context *ctxt);
> static void _mixer_actions_register(E_Mixer_Module_Context *ctxt);
>
> +#ifdef HAVE_ENOTIFY
> static void
> -_mixer_notify(const float val, E_Mixer_Instance *inst __UNUSED__)
> +_mixer_notify_cb(void *data, unsigned int id)
> {
> + E_Mixer_Instance *inst = data;
> +
> + inst->notification_id = id;
> +}
> +#endif
> +
> +static void
> +_mixer_notify(const float val, E_Mixer_Instance *inst)
> +{
> #ifdef HAVE_ENOTIFY
> E_Notification_Notify n;
> E_Mixer_Module_Context *ctxt;
> @@ -65,12 +75,12 @@
> icon = "audio-volume-high";
>
> n.app_name = _("Mixer");
> - n.replaces_id = 0;
> + n.replaces_id = inst->notification_id;
> n.icon.icon = icon;
> n.sumary = _("Volume changed");
> n.body = buf;
> n.timeout = 2000;
> - e_notification_client_send(&n, NULL, NULL);
> + e_notification_client_send(&n, _mixer_notify_cb, inst);
> #endif
> }
>
> @@ -1050,6 +1060,9 @@
> inst->mixer_state.right = inst->conf->state.right;
> inst->mixer_state.left = inst->conf->state.left;
> inst->mixer_state.mute = inst->conf->state.mute;
> +#ifdef HAVE_ENOTIFY
> + inst->notification_id = 0;
> +#endif
> conf->instance = inst;
> if ((!_mixer_sys_setup(inst)) && (!_mixer_sys_setup_defaults(inst)))
> {
>
> Modified: trunk/e/src/modules/mixer/e_mod_main.h
> ===
> --- trunk/e/src/modules/mixer/e_mod_main.h 2013-01-17 10:29:31 UTC
> (rev 82930)
> +++ trunk/e/src/modules/mixer/e
Re: [E-devel] E SVN: ulisses IN trunk/efl/src/lib/evas: canvas common
On Thursday, January 17, 2013, Cedric BAIL wrote: > On Thu, Jan 17, 2013 at 10:57 AM, Cedric BAIL > > > wrote: > > On Thu, Jan 17, 2013 at 7:32 AM, Enlightenment SVN > > > wrote: > >> Log: > >> evas/async_render: fix scalecache integration > >> > >> Note: scalecache is really crazy stuff, we should rewrite it or get > rid of it. > > > > Ah ah ah ! Yet another crazy beast created by our evil overlord, but > > we can't get rid of it as it is a huge speed improvement. As for > > rewriting it, will not be an easy task without generating regression. > > And I can now confirm you that this make the async renderer into a > very good shape. Expedite with async now get a 10% speed increase > overall. Some test are still problematic, the one related with text > style (we should use a variant of the multi call here, same text_prop, > slightly offseted position, different color), the one with many object > (suffer a 10% slow down). > > I think that text style issue should be easy to fix. For the case with > many objects, the only way is to push less information on the queue > somehow, not sure how. > We apply cutouts in the main thread and push individual rectangles to thread. So one obj may spawn multiple regions. To fix this we need to review all cutout to be referenced (hard, because we have some declared as static in functions). Another is to create a result array and send this to a "multiple" variant... That would need a copy and yet another engine call for everything (map, rect, image and font, because the one we use for text grid is different... But maybe just in the common engine, not the virtuals) Overall I believe it's not worth, the great feature of async is reducing the time spent on the main thread. Acidx measured this and should send results soon, we have more uniform and reduced time of "render" in the main thread, so apps have more time to do their stuff. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: seoz trunk/devs/seoz
On Thursday, January 17, 2013, Enlightenment SVN wrote: > Log: > devs/seoz build.sh: Do not build b0rken exquisite due to ecore-fb. It's not broken, just enable it: --enable-fb --disable-tslib Of course you don't need tslib if your running on a desktop. > > Author: seoz > Date: 2013-01-17 01:02:00 -0800 (Thu, 17 Jan 2013) > New Revision: 82925 > Trac: http://trac.enlightenment.org/e/changeset/82925 > > Modified: > trunk/devs/seoz/build.sh > > Modified: trunk/devs/seoz/build.sh > === > --- trunk/devs/seoz/build.sh2013-01-17 07:21:06 UTC (rev 82924) > +++ trunk/devs/seoz/build.sh2013-01-17 09:02:00 UTC (rev 82925) > @@ -32,10 +32,10 @@ > export BUILD_CPP_BINDINGS="BINDINGS/cxx/eflxx BINDINGS/cxx/einaxx > BINDINGS/cxx/evasxx BINDINGS/cxx/ecorexx BINDINGS/cxx/edjexx > BINDINGS/cxx/elementaryxx" > export BUILD_BINDINGS=$BUILD_PYTHON_BINDINGS" "$BUILD_CPP_BINDINGS" " > export BUILD_E_MODULES="E-MODULES-EXTRA/comp-scale E-MODULES-EXTRA/elfe > E-MODULES-EXTRA/engage E-MODULES-EXTRA/forecasts E-MODULES-EXTRA/eweather" > -export BUILD_ETC="terminology ephysics_tests econnman exactness efx > PROTO/shotgun editje PROTO/elev8 PROTO/eyelight ephoto edje_viewer > PROTO/azy elmdentica enlil PROTO/emote emprint clouseau envision ensure > enjoy exquisite rage PROTO/eyesight" > +export BUILD_ETC="terminology ephysics_tests econnman exactness efx > PROTO/shotgun editje PROTO/elev8 PROTO/eyelight ephoto edje_viewer > PROTO/azy elmdentica enlil PROTO/emote emprint clouseau envision ensure > enjoy rage PROTO/eyesight" > export BUILD_EXAMPLE="EXAMPLES/elementary/calculator > EXAMPLES/elementary/converter EXAMPLES/elementary/phonebook > EXAMPLES/elementary/sticky-notes" > export BUILD_GAMES="PROTO/etrophy GAMES/efbb" > -export BUILD_BROKEN="excessive enki espionnage FORMATTING/ecrustify > PROTO/enna-explorer E-MODULES-EXTRA/everything-shotgun " > +export BUILD_BROKEN="excessive enki espionnage FORMATTING/ecrustify > PROTO/enna-explorer E-MODULES-EXTRA/everything-shotgun exquisite" > export BUILD_WITH_CMAKE="ecrire" > > PWD=`pwd` > > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > ___ > 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 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: cedric trunk/efl/src/lib/evas/canvas
On Thursday, January 17, 2013, Enlightenment SVN wrote: > Log: > efl: stupid micro optimization. > > This single test accounted for 1% of my terminology benchmark. > I am considering moving evas_string_char_next_get and > eina_unicode_utf8_get_next to become inline as their function > entry/exit point account for 3% of the same benchmark. > > The biggest win would be to get rid of the memcpy _termpty_text_copy > that account for 16%. > > In the micro optimization part, we also still do to much malloc > in font_draw_prepare as we don't recycle the array there and account > for 3% of the benchmark in malloc/free there. In the same ballpark > _text_save_top account for 2% of the time in malloc/free. > > In that same benchmark, evas_object_textgrid_render account for 5% > where 4% of its time is spend in evas_common_font_draw_prepare. At this > point I am not sure that rewriting textgrid is gona help us at all. We > will win almost as much by just inlining the get_next things in evas > and eina for a minute of development time. It's a bit naive to think so, because you'd be able to change the algorithm and avoid conversions. All in all you could just give engine the same array that terminology fills (cell row array), together with region and context (clipper, cutouts) and glyph bitmap. Particularly the glyph bitmap could be optimized as its an int hash, but we know A-Za-z0-9 ate hot, we could have ASCII printable range in an array while everything else goes to a hash -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk/efl: . src
On 17/01/13 06:43, Cedric BAIL wrote: > On Wed, Jan 16, 2013 at 5:51 AM, Enlightenment SVN > wrote: >> Log: >> efl: use autotools testsuite for running tests >> >>Instead of just making our own "check-local" and calling the binaries >>ourselves, just append them into "TESTS" variable. Then they run after >>all check_PROGRAMS are compiled. >> >>The reasons for changing are: >> 1) If we change the test and call "make check" the test is not >> compiled again -- and the only way to compile it is to "make clean". >> 2) There's no need to reinvent the wheel here. >> >>With a recent version of Automake, the test output is redirected to log >>files. This is good but unexpected for whom was used to the previous >>way. So, be warned. > > Where is that log file ? We want it to print to stdout/err because we need it to show in buildbot... Could you at least add a "cat" afterwards to dump the log files so they'll show in buildbot or something? Unless I didn't get you right... Thanks, Tom. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/efl: . licenses
Hello, flamewar++; On 01/17/2013 03:19 AM, David Seikel wrote: > > The debate will rage on once more. The people that thought they where > licensing their code under BSD will mewl ineffectively about their > rights being taken away. The GPL people will smugly and effectively say the trouble I have with people complaining about their BSD licensed code being "taken away" is that it is precisely this feature that makes them want to use the BSD license in the first place. :-) Though no one complains about the pieces of BSD code that get modified and re-licensed under a proprietary license because no-one can see this code and complain that they can't use it. Somehow this code being out in the open and available for all to see (and for some to use) makes it worse and caused people to actively hate this license. I completely agree with Gustavo about the area of what the freedom covers being different. BSD gives freedom to the developer, GPL and variants grant the right to freedom to the code. Both come with certain issues, but I strongly believe that without the GPL the whole Open/Libre Source ecosystem (and in conclusion EFL) would not exist in its current form, not even close. None of these arguments make any concrete case why the EFL should be licensed one way or the other and I personally am fine with either. It's just that I don't understand "the BSD people" (or corporations for that matter) why they have this problem with the GPL in particular. Maybe someone can enlighten me. I will also refrain from any more public answers on this topic because everyone has their Correct opinion on this. (flamewar--;) Regards, Daniel "this is my personal and most likely not my employer's opinion" Willmann -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: thanatermesis IN trunk/e/config: default standard
On Wed, 16 Jan 2013 16:57:53 -0800 "Enlightenment SVN" wrote: > Log: > added missing conf for screen_limits (new lost windows) > > Author: thanatermesis > Date: 2013-01-16 16:57:53 -0800 (Wed, 16 Jan 2013) > New Revision: 82913 > Trac: http://trac.enlightenment.org/e/changeset/82913 > > Modified: > trunk/e/config/default/e.src trunk/e/config/standard/e.src > > Modified: trunk/e/config/default/e.src > === > --- trunk/e/config/default/e.src 2013-01-16 22:32:39 UTC (rev 82912) > +++ trunk/e/config/default/e.src 2013-01-17 00:57:53 UTC (rev 82913) > @@ -479,6 +479,7 @@ >value "theme_default_border_style" string: "default"; >value "desk_auto_switch" int: 0; >value "thumb_nice" int: 0; > + value "screen_limits" int: 0; >value "menu_favorites_show" int: 1; >value "menu_apps_show" int: 1; >value "ping_clients_interval" int: 16; > > Modified: trunk/e/config/standard/e.src > === > --- trunk/e/config/standard/e.src 2013-01-16 22:32:39 UTC (rev 82912) > +++ trunk/e/config/standard/e.src 2013-01-17 00:57:53 UTC (rev 82913) > @@ -161,6 +161,7 @@ > value "theme_default_border_style" string: "default"; > value "desk_auto_switch" int: 0; > value "thumb_nice" int: 0; > +value "screen_limits" int: 0; > value "menu_favorites_show" int: 1; > value "menu_apps_show" int: 1; > value "ping_clients_interval" int: 128; > this commit has no effect. you are aware of that, I assume? -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
