On Fri, 9 Oct 2009 16:59:37 -0300 Iván Briano (Sachiel) <sachi...@gmail.com> said:
> On Fri, Oct 9, 2009 at 4:46 PM, Nicolas Aguirre > <aguirre.nico...@gmail.com> wrote: > > 2009/10/9 Iván Briano (Sachiel) <sachi...@gmail.com>: > >> > >> It's not a problem with table or list, but evas_box and evas_table inherit > >> from evas_object_smart_clipped, which uses a smaller clipper than the > >> smart objects in elm were. Increasing the size of the clipper "fixes" it, > >> but you will run into the same problem if you keep growing the table. > >> > >> I just commited a bigger clipper, managed to get 1000 columns in the > >> table just fine, albeit very slow to scroll, and that's already an insanely > >> big number for elm_table. > >> > > > > It's usable with SVN < 42781, you can scroll 3x2000 items without lag > > in test_photo. but it's very very very slow with recent SVN. But as I > > said in my previous mail, table creation is much faster with > > evas_table. > > > > Test with 3x2000 items : > > SVN < 42781 : Table creation take 38.868 seconds, scroll is smotth. > > SVN r42984 : Table creation take 'only' 1.329 seconds. you can't > > scroll at least on my core2 duo. > > > > I can't test that now, but I *could* scroll the table with a huge ammount > of objects, it was just noticeably slower. > I'll look into this with more detail during the weekend. > > > I agree that it's not very smart to add so many items in a table and > > show all of them in the same time. But IIR you can't use elm_genlist > > in horizontal mode. And I use a lot of elm_box in enna. And with these > > last commits, it's very slow :/ > > But I find it unfortunate to have changed something that was really > > fast and reliable to evas_box that seems much slower, maybe we should > > try to fix evas_box before switching ? > > > > Both evas_box and evas_table were there for some time already and no one > touched them, it's much more likely that they'll get fixed now that elm moved > to them. actually the move to evas_box/table broke a slew of things. index, scrolling in photocam and scrolling in several other tests. one reason is that the smart table/box would calc their min size on every add - thus its alweasy available as "current". evas table/box are faster on inserts because they dont do this.. but thsi emans the min size is not known until some time later (or u explicitly call calc) i suspect this has triggered a small mountain of issues. i added something to foce a canvas-wide calc BEFORE any window show because one effect was windows coming up "1x1" pixel THEN resizing to be bigger as min size wasn't known until after first render. i added to edje the ability to listen to size hint changes and auto-adjust the swallowed element. this reduced some swallows in the code as its not needed anymore, but i suspect this has given rise to other problems. i suggest you try every test and look at them in detail. but something bad happened (tm). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
