Re: [E-devel] Evas memory consumption with async render.
On Tue, Jan 8, 2013 at 12:59 AM, Carsten Haitzler ras...@rasterman.comwrote: On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: first... i ran a valgrind run overnight... hooray! the witch is dead.. errr. i mean the leak is gone. awesome! http://www.enlightenment.org/ss/e-50eb86c540c731.34017080.png so no leak there. lot of big peaks, but no leak. good! but that brings us to the topic of your mail... the peaks.. and they are really big compared to the baseline and that is a concern. mine seems nastier (6m-29m) that yours... indeed, it will depend on how many chars it issued. As I said it will queue one font draw command per cell :-( this is fixable, but there are characteristics that will keep doing that. For instance we apply cutouts in the main thread, and this produces one thread command per remaining region. In a nasty case if you produce lots of 1x1 regions it will generate that many useless commands. The way to fix this would include touching every place where cutout rects is used and it would be way more error prone, almost impossible to get right (and optimizations to reuse cutout rects would be even harder!) Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is not showing any abnormal behavior either, this is with EFL SVN (single tree). confirmed. :) What we found is that textgrid implementation will have to change. Right now it's very below what it should be, and for every cell it will issue 3 commands: one rectangle_draw() for BG, one font_draw() and one hmm not for rect. it will merge rects within a row. so a row with all the same colored bg will draw a single rect as the bg (for that row). see evas_object_textgrid_render() the if (!run)... it starts a new rect, if it detects a run of the same colored rect.. (c-r/g/b match rr./gg/bb) it expands the rect width, if color changes... it begins a new rect run. :) so from that pov i think we're good. Ok, I did not read the code more than 20 minutes and did not notice this was done already. sure - underline and strikethrough dont get merged. there's an XXX: for that - i just found them to be so rare, that i didn't bother. :) indeed merging these into a run would be good too... the issue at hand really is the text. yes. it issues a text draw PER char it draws in a row (of course empty cells get no draw call). ok, then if you think this could be simplified to just text, would make it easier. But I'd go with a full engine based textgrid implementation :-P rectangle_draw() for underline/strikeout. 80 x 24 x 3 = 5760 commands being queued to the thread! I wonder why it's not unusable slow, given that it will lock the mutex, append to queue, dequeue and so on :-P :) just fyi... it is a text draw per call to ENSURE a grid. it can't merge into a string because it does handle proportional fonts (on a best effort basis). this means we have to FORCE the fonts into the grid by drawing 1 char at a time. That I've noticed, even said that in my reply to Tasn. The idea is to rewrite textgrid to have its own row_draw() or similar exported to the engine, which can optimize the drawing. First we'll tackle the rewrite, but optimizations could be applied later such as collapsing sibling background or line rectangles if color match, doing a single operation. it's already there. sure - it's not a row draw func.. its just the inner for (xx = 0... loop - and bg's are collapsed together. strikethrough/underline could be if that seems an issue (as above - not common enough to worry, but if you find it more common - sure). the problem is mostly the text. it's a bi-product of having to maintain a grid. That's not one day task, so we'll ask you to wait a bit until it get fixed. sure - but i think we need to discuss the solution as i think you missed what the code is doing. it first walks the cells and builds a row array - with each row array being an array of commands draw rect/text basically (with underline/strikethrough being lines - ie 1 pixel high rects). it THEN walks that array of commands and issues the draw commands in phase 2. that i got, except the merge of rectangles that I supposed were doing naively, one rect per cell as well. the question is how to improve this. reality is that we cant convert to strings WITHOUT having a way to force the string/font/text renderer to enforce a grid spacing of text - this is one option. but then we re-generate textprops all the time ... or we have to restructure it in textgrid to not store textprops per cell but genrate runs at rendering time - but then scrolling means re-generate as scrolling isnt a special op... we just
[E-devel] Evas memory consumption with async render.
Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is not showing any abnormal behavior either, this is with EFL SVN (single tree). What we found is that textgrid implementation will have to change. Right now it's very below what it should be, and for every cell it will issue 3 commands: one rectangle_draw() for BG, one font_draw() and one rectangle_draw() for underline/strikeout. 80 x 24 x 3 = 5760 commands being queued to the thread! I wonder why it's not unusable slow, given that it will lock the mutex, append to queue, dequeue and so on :-P The idea is to rewrite textgrid to have its own row_draw() or similar exported to the engine, which can optimize the drawing. First we'll tackle the rewrite, but optimizations could be applied later such as collapsing sibling background or line rectangles if color match, doing a single operation. That's not one day task, so we'll ask you to wait a bit until it get fixed. As for e17 and other said leaks, please check with valgrind if it's leaking or what. Also please run with EINA_MEMPOOL_PASS=1 to see if it's leaking or still being held by mempool caches/buffers. -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
I'm not sure there's a need for a specific row_draw, I think using the regular font_draw (with possible adjustments for fake-monospace) should be enough. On Mon, Jan 7, 2013 at 7:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is not showing any abnormal behavior either, this is with EFL SVN (single tree). What we found is that textgrid implementation will have to change. Right now it's very below what it should be, and for every cell it will issue 3 commands: one rectangle_draw() for BG, one font_draw() and one rectangle_draw() for underline/strikeout. 80 x 24 x 3 = 5760 commands being queued to the thread! I wonder why it's not unusable slow, given that it will lock the mutex, append to queue, dequeue and so on :-P The idea is to rewrite textgrid to have its own row_draw() or similar exported to the engine, which can optimize the drawing. First we'll tackle the rewrite, but optimizations could be applied later such as collapsing sibling background or line rectangles if color match, doing a single operation. That's not one day task, so we'll ask you to wait a bit until it get fixed. As for e17 and other said leaks, please check with valgrind if it's leaking or what. Also please run with EINA_MEMPOOL_PASS=1 to see if it's leaking or still being held by mempool caches/buffers. -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
On Mon, Jan 7, 2013 at 5:50 PM, Tom Hacohen t...@stosb.com wrote: I'm not sure there's a need for a specific row_draw, I think using the regular font_draw (with possible adjustments for fake-monospace) should be enough. It's not, and it will be a super waste as this will apply cutouts and everything per char! with specific grid render function system can better know and optimize. As I said, it can collapse sibling rectangles (bg, think of ncurses, it's a single rectangle for 10x20 ncurse windows, not 200), and underline... also it can be smarter when drawing the text. -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
Oh you were talking about the whole grid, not just the text. Well as for the grid itself (background for example) textgrid should do this logic on it's own, why would it need an engine to merge rects? This way textgrid will be able to do it for more than just one row... As for text: the current font_draw will handle a line just fine, unless I don't understand you correctly. -- Tom. On Mon, Jan 7, 2013 at 8:37 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Jan 7, 2013 at 5:50 PM, Tom Hacohen t...@stosb.com wrote: I'm not sure there's a need for a specific row_draw, I think using the regular font_draw (with possible adjustments for fake-monospace) should be enough. It's not, and it will be a super waste as this will apply cutouts and everything per char! with specific grid render function system can better know and optimize. As I said, it can collapse sibling rectangles (bg, think of ncurses, it's a single rectangle for 10x20 ncurse windows, not 200), and underline... also it can be smarter when drawing the text. -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
On Mon, Jan 7, 2013 at 6:47 PM, Tom Hacohen t...@stosb.com wrote: Oh you were talking about the whole grid, not just the text. Well as for the grid itself (background for example) textgrid should do this logic on it's own, why would it need an engine to merge rects? This way textgrid will be able to do it for more than just one row... the bg color coalescing/merge yes, could be done. Yet in many cases it wouldn't help yet. if you have alternating colors, it would still issue one context_set() + rectangle_draw() PER char, that will calculate color multiply, that would apply cutouts... and of course generate one useless thread command. The render engine could do better at that. Really I'm even thinking about exposing the Evas_Textgrid_Cell to the engine, removing the need to convert it to its own structure as it's now. It's more efficient, as you can use the indexed palette to save space and operations when looking for colors and multiply. Bad is only that Eina_Unicode codepoint would require exposing the translation to glyph. As for text: the current font_draw will handle a line just fine, unless I don't understand you correctly. evas_object_textgrid_size_set() can change the grid cell size, then we'd have to ignore the usual kerning/spacing and use that. We'd have to work to fix and make it usable. with a custom textgrid engine we can simplify the loop: for (y = y0; y y1; y += h) for (x = x0; x x1; x += w, glyph++) draw(x, y, w, h, *glyph) -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is not showing any abnormal behavior either, this is with EFL SVN (single tree). I'm not using terminology, or any long running text grid users. I can confirm that E17 with merged EFL tree is not leaking any more than usual. At least for me. B-) -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
Hi David, On Mon, Jan 7, 2013 at 8:31 PM, David Seikel onef...@gmail.com wrote: On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is not showing any abnormal behavior either, this is with EFL SVN (single tree). I'm not using terminology, or any long running text grid users. I can confirm that E17 with merged EFL tree is not leaking any more than usual. At least for me. B-) Since when? Do you know? 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
On Mon, Jan 7, 2013 at 8:21 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is not showing any abnormal behavior either, this is with EFL SVN (single tree). What we found is that textgrid implementation will have to change. Right now it's very below what it should be, and for every cell it will issue 3 commands: one rectangle_draw() for BG, one font_draw() and one rectangle_draw() for underline/strikeout. 80 x 24 x 3 = 5760 commands being queued to the thread! I wonder why it's not unusable slow, given that it will lock the mutex, append to queue, dequeue and so on :-P The idea is to rewrite textgrid to have its own row_draw() or similar exported to the engine, which can optimize the drawing. First we'll tackle the rewrite, but optimizations could be applied later such as collapsing sibling background or line rectangles if color match, doing a single operation. That's not one day task, so we'll ask you to wait a bit until it get fixed. As for e17 and other said leaks, please check with valgrind if it's leaking or what. Also please run with EINA_MEMPOOL_PASS=1 to see if it's leaking or still being held by mempool caches/buffers. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 Hi gustavo, I'm a gentoo user, using terminology as my main terminal, and as you know, running gentoo alone is usually stressful enough for a terminal :) In the 3 or 4 weeks I'm running the single-efl tree now, I haven't seen any noticable mem-leaks, and my terminals are usually open for days. Just now, I threw some 100k lines (N * 2000 lines ^= (while; do dmesg; done)) on one terminology window for an hour, and I can not even see small leaks. The mem usage is between 40M and 50M and did not increase over time at all. It will stay at 36M after this, which should be the 10k lines scrollback-buffer. -- thomasg -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas memory consumption with async render.
On Tue, Jan 8, 2013 at 6:13 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Jan 7, 2013 at 6:47 PM, Tom Hacohen t...@stosb.com wrote: Oh you were talking about the whole grid, not just the text. Well as for the grid itself (background for example) textgrid should do this logic on it's own, why would it need an engine to merge rects? This way textgrid will be able to do it for more than just one row... the bg color coalescing/merge yes, could be done. Yet in many cases it wouldn't help yet. if you have alternating colors, it would still issue one context_set() + rectangle_draw() PER char, that will calculate color multiply, that would apply cutouts... and of course generate one useless thread command. The render engine could do better at that. Really I'm even thinking about exposing the Evas_Textgrid_Cell to the engine, removing the need to convert it to its own structure as it's now. It's more efficient, as you can use the indexed palette to save space and operations when looking for colors and multiply. Be careful, their is one optimization here. We do recycle text_prop as creating them is costly and we do almost always use the same character in a terminal, so it is good to recycle them instead of creating and destroying them. If you are going to add a text row render to recycle information. -- Cedric BAIL -- 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
Re: [E-devel] Evas memory consumption with async render.
On Mon, 7 Jan 2013 17:21:36 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: first... i ran a valgrind run overnight... hooray! the witch is dead.. errr. i mean the leak is gone. awesome! http://www.enlightenment.org/ss/e-50eb86c540c731.34017080.png so no leak there. lot of big peaks, but no leak. good! but that brings us to the topic of your mail... the peaks.. and they are really big compared to the baseline and that is a concern. mine seems nastier (6m-29m) that yours... Today acidx and pcajr investigated it heavily, we need help from people suffering as we can't confirm. As one can see, there is a peak, but then it will go back: http://www.zytor.com/~pcacjr/misc/2013-01-07-170102_1920x1080_scrot.png This is terminology run with compilation inside. E17 is not showing any abnormal behavior either, this is with EFL SVN (single tree). confirmed. :) What we found is that textgrid implementation will have to change. Right now it's very below what it should be, and for every cell it will issue 3 commands: one rectangle_draw() for BG, one font_draw() and one hmm not for rect. it will merge rects within a row. so a row with all the same colored bg will draw a single rect as the bg (for that row). see evas_object_textgrid_render() the if (!run)... it starts a new rect, if it detects a run of the same colored rect.. (c-r/g/b match rr./gg/bb) it expands the rect width, if color changes... it begins a new rect run. :) so from that pov i think we're good. sure - underline and strikethrough dont get merged. there's an XXX: for that - i just found them to be so rare, that i didn't bother. :) indeed merging these into a run would be good too... the issue at hand really is the text. yes. it issues a text draw PER char it draws in a row (of course empty cells get no draw call). rectangle_draw() for underline/strikeout. 80 x 24 x 3 = 5760 commands being queued to the thread! I wonder why it's not unusable slow, given that it will lock the mutex, append to queue, dequeue and so on :-P :) just fyi... it is a text draw per call to ENSURE a grid. it can't merge into a string because it does handle proportional fonts (on a best effort basis). this means we have to FORCE the fonts into the grid by drawing 1 char at a time. The idea is to rewrite textgrid to have its own row_draw() or similar exported to the engine, which can optimize the drawing. First we'll tackle the rewrite, but optimizations could be applied later such as collapsing sibling background or line rectangles if color match, doing a single operation. it's already there. sure - it's not a row draw func.. its just the inner for (xx = 0... loop - and bg's are collapsed together. strikethrough/underline could be if that seems an issue (as above - not common enough to worry, but if you find it more common - sure). the problem is mostly the text. it's a bi-product of having to maintain a grid. That's not one day task, so we'll ask you to wait a bit until it get fixed. sure - but i think we need to discuss the solution as i think you missed what the code is doing. it first walks the cells and builds a row array - with each row array being an array of commands draw rect/text basically (with underline/strikethrough being lines - ie 1 pixel high rects). it THEN walks that array of commands and issues the draw commands in phase 2. the question is how to improve this. reality is that we cant convert to strings WITHOUT having a way to force the string/font/text renderer to enforce a grid spacing of text - this is one option. but then we re-generate textprops all the time ... or we have to restructure it in textgrid to not store textprops per cell but genrate runs at rendering time - but then scrolling means re-generate as scrolling isnt a special op... we just change the grid array. another option is the ability to have a multi textprop draw cmd added to engines - this renders using an array of N textprops so you place a single font draw cmd on the cmdqueue for the thread but it has multiple tp's attached. also textprops are not that small... were we really only need some of the data in this case... maybe we can trim that down? As for e17 and other said leaks, please check with valgrind if it's leaking or what. Also please run with EINA_MEMPOOL_PASS=1 to see if it's leaking or still being held by mempool caches/buffers. -- 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. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412
