Simon TRENY escreveu: [snip] > Here I fully disagree. I played a little bit with ewl_tree_test, and I > replaced the ROWS constant by 3000 (it was initially to 50) and I > removed the NEST modulo just to make sure all the rows will be directly > children of the tree itself (no collapsed rows). Result? It takes > approximatively 2 mins for the window to appear, scrolling is laggy as > hell, and (I don't why) it caused the shutdown of ewl_test after 30 secs > of use (no segv, just a shutdown). And hopefully, you've coded a > function to know the heap size. So here is the result: "HEAP SIZE: > 71053312 bytes". Yes, more than 70Mb for 3000 rows. And I don't see how > you can improve the situation without limitating the type of widgets you > can add to the tree. Even if "2950 * num_of_rows * > num_of_evas_objects_by_widget" evas_objects are hidden, they are still > processed by the rendering pipe of evas, and worst they still remain in > memory.
Disclaimer: I'm not familiar with EWL/Evas internals. Can the items be made proxies for the real widgets, and just keep the amount of items created for how many can be visible, and assign the widgets to them as the widget scroll? If the item isnt visible, you would free it or add it to a pool. Maybe a mix of both, based on a threshold. This way, you keep the number of items send to evas small, and still can have a mixed item approach. Solerman ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
