[E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
Hello all, Loading (startup) performance problem: -- I just had time to look at the elm_genlist performance problem again. Sometime ago, I asked the list about elm_genlist's walking through the list at startup in order to determine the list's width and height. However, the performance problem when loading a huge list of items to a genlist still persists. While it is okay on my desktop, it really freezes up my target (ARM926ejs @ 400MHz) for quite some time. I suggest adding a new API: elm_genlist_homogeneous_set(Evas_Object *obj, Eina_Bool homogeneous) to let the genlist know about the list's nature and uses the first item's width and height as a reference for the remaining list items. 'homogeneous' also implies 'compress' mode. On my target, it loads 1000+ items fine this way without rendering the system unresponsive. genlist already does lazy-loading quite well. This will make it 'lazier' if the list items are of the same size. Scrolling performance problem: -- Also, I suggest adding another API: elm_genlist_block_count_set(Evas_Object *obj, int max) to let the programmer decides what's the optimal block size for his/her particular target. I believe this value is currently hard-coded '32'. The problem is that when the idler renders this chunk of items, it will slow down the system when the user scrolls around outside the 32-item block already rendered. I already tested my version on my target. It seems to work quite well even on a big list (1000+ items). Any thoughts? Thanks in advance for inputs. brian -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
2010/1/21 Brian Wang > Hello all, > > Loading (startup) performance problem: > -- > I just had time to look at the elm_genlist performance problem again. > Sometime ago, I asked the list about elm_genlist's walking through the > list at startup in order to determine the list's width and height. > However, the performance problem when loading a huge list of items to > a genlist still persists. While it is okay on my desktop, it really > freezes up my target (ARM926ejs @ 400MHz) for quite some time. > > I suggest adding a new API: > elm_genlist_homogeneous_set(Evas_Object *obj, Eina_Bool homogeneous) > to let the genlist know about the list's nature and uses the first > item's width and height as a reference for the remaining list items. > 'homogeneous' also implies 'compress' mode. > On my target, it loads 1000+ items fine this way without rendering the > system unresponsive. > genlist already does lazy-loading quite well. This will make it > 'lazier' if the list items are of the same size. > I agree, this is a great idea and will help a lot. Generally items have the same height. > > Scrolling performance problem: > -- > Also, I suggest adding another API: > elm_genlist_block_count_set(Evas_Object *obj, int max) > to let the programmer decides what's the optimal block size for > his/her particular target. I believe this value is currently > hard-coded '32'. The problem is that when the idler renders this > chunk of items, it will slow down the system when the user scrolls > around outside the 32-item block already rendered. > > I already tested my version on my target. It seems to work quite well > even on a big list (1000+ items). > > Any thoughts? Thanks in advance for inputs. > > Good idea. > > > brian > > -- > brian > -- > > Cool-Karaoke - The smallest recording studio, in your palm, open-sourced > http://cool-idea.com.tw/ > > iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe > > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Regards. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Thu, Jan 21, 2010 at 8:30 AM, Atton Jonathan wrote: > 2010/1/21 Brian Wang > >> Hello all, >> >> Loading (startup) performance problem: >> -- >> I just had time to look at the elm_genlist performance problem again. >> Sometime ago, I asked the list about elm_genlist's walking through the >> list at startup in order to determine the list's width and height. >> However, the performance problem when loading a huge list of items to >> a genlist still persists. While it is okay on my desktop, it really >> freezes up my target (ARM926ejs @ 400MHz) for quite some time. >> >> I suggest adding a new API: >> elm_genlist_homogeneous_set(Evas_Object *obj, Eina_Bool homogeneous) >> to let the genlist know about the list's nature and uses the first >> item's width and height as a reference for the remaining list items. >> 'homogeneous' also implies 'compress' mode. >> On my target, it loads 1000+ items fine this way without rendering the >> system unresponsive. >> genlist already does lazy-loading quite well. This will make it >> 'lazier' if the list items are of the same size. >> > > I agree, this is a great idea and will help a lot. Generally items have the > same height. I also agree with that. And to say more, just like I did with Guarana's list, we should abstract the model it uses, providing functions to check the number of items and get items given its index. That way we can write those functions that query SQL and no need to actually create a list with 1000 elements in order to show it. This abstraction would also make it easier for python and other bindings, as it would be possible to walk "native" (python, perl...) without actually converting the huge elm_genlist calls. hint: I created eina_accessor to help with such thing. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
2010/1/21 Gustavo Sverzut Barbieri : > On Thu, Jan 21, 2010 at 8:30 AM, Atton Jonathan > wrote: >> 2010/1/21 Brian Wang >> >>> Hello all, >>> >>> Loading (startup) performance problem: >>> -- >>> I just had time to look at the elm_genlist performance problem again. >>> Sometime ago, I asked the list about elm_genlist's walking through the >>> list at startup in order to determine the list's width and height. >>> However, the performance problem when loading a huge list of items to >>> a genlist still persists. While it is okay on my desktop, it really >>> freezes up my target (ARM926ejs @ 400MHz) for quite some time. >>> >>> I suggest adding a new API: >>> elm_genlist_homogeneous_set(Evas_Object *obj, Eina_Bool homogeneous) >>> to let the genlist know about the list's nature and uses the first >>> item's width and height as a reference for the remaining list items. >>> 'homogeneous' also implies 'compress' mode. >>> On my target, it loads 1000+ items fine this way without rendering the >>> system unresponsive. >>> genlist already does lazy-loading quite well. This will make it >>> 'lazier' if the list items are of the same size. >>> >> >> I agree, this is a great idea and will help a lot. Generally items have the >> same height. > > I also agree with that. > > And to say more, just like I did with Guarana's list, we should > abstract the model it uses, providing functions to check the number of > items and get items given its index. That way we can write those > functions that query SQL and no need to actually create a list with > 1000 elements in order to show it. > > This abstraction would also make it easier for python and other > bindings, as it would be possible to walk "native" (python, perl...) > without actually converting the huge elm_genlist calls. > > hint: I created eina_accessor to help with such thing. > It would be perfect :) -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://www.digital-corner.org -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
Am Donnerstag, den 21.01.2010, 10:26 -0200 schrieb Gustavo Sverzut Barbieri: > And to say more, just like I did with Guarana's list, we should > abstract the model it uses, providing functions to check the number of > items and get items given its index. That way we can write those > functions that query SQL and no need to actually create a list with > 1000 elements in order to show it. Yep. This is actually how other modern MVC-toolkits are doing that -- the UITableView in Cocoa Touch is an amazing example for it. -- :M: -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Thu, Jan 21, 2010 at 2:53 PM, Michael 'Mickey' Lauer wrote: > Am Donnerstag, den 21.01.2010, 10:26 -0200 schrieb Gustavo Sverzut > Barbieri: >> And to say more, just like I did with Guarana's list, we should >> abstract the model it uses, providing functions to check the number of >> items and get items given its index. That way we can write those >> functions that query SQL and no need to actually create a list with >> 1000 elements in order to show it. > > Yep. This is actually how other modern MVC-toolkits are doing that -- > the UITableView in Cocoa Touch is an amazing example for it. Yes, it's simple and actually implemented in Guarana. Just need someone with time (don't look at me!) to go and port it to Elementary. http://local.profusion.mobi:8081/cgit.cgi/guarana.git/tree/src/lib/widgets more specifically: http://local.profusion.mobi:8081/cgit.cgi/guarana.git/tree/src/lib/widgets/base_list.c (grn_base_list_model_api_set) http://local.profusion.mobi:8081/cgit.cgi/guarana.git/tree/src/lib/widgets/single_selection_list.c the bad thing atm is that it does not play elm_scroller panning interface, implementing its own. Then you can either port it to use that, or add the model_api_set() to genlist (probably easier) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
[snip] > > And to say more, just like I did with Guarana's list, we should > abstract the model it uses, providing functions to check the number of > items and get items given its index. That way we can write those > functions that query SQL and no need to actually create a list with > 1000 elements in order to show it. I'm not an expert of this, so bear with me. :-) You mean saving items into an SQL database and SELECT them on demand? If the database is on a disk (not RAM), wouldn't it be slow when the list is scrolled around due to the querying? If the database is in RAM, how is it different from the current implementation in terms of memory footprint? > > This abstraction would also make it easier for python and other > bindings, as it would be possible to walk "native" (python, perl...) > without actually converting the huge elm_genlist calls. > > hint: I created eina_accessor to help with such thing. > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Fri, Jan 22, 2010 at 9:28 AM, Carsten Haitzler wrote: > On Fri, 22 Jan 2010 09:15:44 +0800 Brian Wang > said: > >> [snip] >> > >> > And to say more, just like I did with Guarana's list, we should >> > abstract the model it uses, providing functions to check the number of >> > items and get items given its index. That way we can write those >> > functions that query SQL and no need to actually create a list with >> > 1000 elements in order to show it. >> >> I'm not an expert of this, so bear with me. :-) >> You mean saving items into an SQL database and SELECT them on demand? >> If the database is on a disk (not RAM), wouldn't it be slow when the >> list is scrolled around due to the querying? If the database is in >> RAM, how is it different from the current implementation in terms of >> memory footprint? > > thats what genlist does now - it doesnt select itself - you provide the > callbacks in your item class as to how to get the data. it's up to you how to > do thats > > what is different is there is an add stage. you add all the items (as each > item > can be a different class - ie style or content). the only differencce between > what genlist does now and what gustavo is proposing is - who calls the adds. > > genlist needs to know what to call for each item to get its content - and > what > style to display it in. as such there is no way to do this without first > telling genlist which items are of what type. > > ONLY in the case where all items are of the same size (regular grid) can you > take possible shortcuts and just get item count and thus determine list height > from my previous mail - width needs to also then be fixed. Yes. Homogeneous mode also implies 'compress' mode to limit the width to its container. > > you are creating a very special-case list. genlist is genlist.. because its.. > generic. it can handle anything you throw at it. every item can be a different > style, and different size. genlist has its own deferred queue for adding items > that it processes in idle time to keep it "fast" > > i'm not sure about what brian says - that the app becomes unresponsive. i've > run this on lower-end arm's (armv6 - 800mhz - yes thats lower end these days!) > and it runs just danndily on my test case with 2000, 1 or more items. it > takes a while to populate the list, but u can scroll around and do things. By unresponsive, I mean that the scrolling becomes stuttering. Well, I'm running it on a "lower-end" arm with 64MB of DDR. What I could think of the difference other than the computing power is that my list contains Chinese characters. I reason that freetype tends to render Chinese charset slower due to the fact that the huge range of Chinese character set does not fit into a reasonable-sized font cache. And of course, armv6 vs armv5te, CPU core speed, DDR (I assume it's on your target too) bus speed (mine is 133/266 with 16-bit data bus...) all make big difference. However, it's the difficulty of life that I have to cope with. :-) > >> > This abstraction would also make it easier for python and other >> > bindings, as it would be possible to walk "native" (python, perl...) >> > without actually converting the huge elm_genlist calls. >> > >> > hint: I created eina_accessor to help with such thing. >> > >> > >> > -- >> > Gustavo Sverzut Barbieri >> > http://profusion.mobi embedded systems >> > -- >> > MSN: barbi...@gmail.com >> > Skype: gsbarbieri >> > Mobile: +55 (19) 9225-2202 >> > >> >> >> >> -- >> brian >> -- >> >> Cool-Karaoke - The smallest recording studio, in your palm, open-sourced >> http://cool-idea.com.tw/ >> >> iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe >> >> -- >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues through >> interactions with peers, luminaries and emerging and established companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> ___ >> 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 > > -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues throu
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Thu, 21 Jan 2010 17:04:32 +0800 Brian Wang said: sounds ok - u missed something. this isnt just height. width. and width it determined by content (eg how long is the text label). and... that can vary WILDLY. you'd have to have width fixed too. > Hello all, > > Loading (startup) performance problem: > -- > I just had time to look at the elm_genlist performance problem again. > Sometime ago, I asked the list about elm_genlist's walking through the > list at startup in order to determine the list's width and height. > However, the performance problem when loading a huge list of items to > a genlist still persists. While it is okay on my desktop, it really > freezes up my target (ARM926ejs @ 400MHz) for quite some time. > > I suggest adding a new API: > elm_genlist_homogeneous_set(Evas_Object *obj, Eina_Bool homogeneous) > to let the genlist know about the list's nature and uses the first > item's width and height as a reference for the remaining list items. > 'homogeneous' also implies 'compress' mode. > On my target, it loads 1000+ items fine this way without rendering the > system unresponsive. > genlist already does lazy-loading quite well. This will make it > 'lazier' if the list items are of the same size. > > Scrolling performance problem: > -- > Also, I suggest adding another API: > elm_genlist_block_count_set(Evas_Object *obj, int max) > to let the programmer decides what's the optimal block size for > his/her particular target. I believe this value is currently > hard-coded '32'. The problem is that when the idler renders this > chunk of items, it will slow down the system when the user scrolls > around outside the 32-item block already rendered. > > I already tested my version on my target. It seems to work quite well > even on a big list (1000+ items). > > Any thoughts? Thanks in advance for inputs. > > > > brian > > -- > brian > -- > > Cool-Karaoke - The smallest recording studio, in your palm, open-sourced > http://cool-idea.com.tw/ > > iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > ___ > 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 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Fri, 22 Jan 2010 09:15:44 +0800 Brian Wang said: > [snip] > > > > And to say more, just like I did with Guarana's list, we should > > abstract the model it uses, providing functions to check the number of > > items and get items given its index. That way we can write those > > functions that query SQL and no need to actually create a list with > > 1000 elements in order to show it. > > I'm not an expert of this, so bear with me. :-) > You mean saving items into an SQL database and SELECT them on demand? > If the database is on a disk (not RAM), wouldn't it be slow when the > list is scrolled around due to the querying? If the database is in > RAM, how is it different from the current implementation in terms of > memory footprint? thats what genlist does now - it doesnt select itself - you provide the callbacks in your item class as to how to get the data. it's up to you how to do thats what is different is there is an add stage. you add all the items (as each item can be a different class - ie style or content). the only differencce between what genlist does now and what gustavo is proposing is - who calls the adds. genlist needs to know what to call for each item to get its content - and what style to display it in. as such there is no way to do this without first telling genlist which items are of what type. ONLY in the case where all items are of the same size (regular grid) can you take possible shortcuts and just get item count and thus determine list height from my previous mail - width needs to also then be fixed. you are creating a very special-case list. genlist is genlist.. because its.. generic. it can handle anything you throw at it. every item can be a different style, and different size. genlist has its own deferred queue for adding items that it processes in idle time to keep it "fast" i'm not sure about what brian says - that the app becomes unresponsive. i've run this on lower-end arm's (armv6 - 800mhz - yes thats lower end these days!) and it runs just danndily on my test case with 2000, 1 or more items. it takes a while to populate the list, but u can scroll around and do things. > > This abstraction would also make it easier for python and other > > bindings, as it would be possible to walk "native" (python, perl...) > > without actually converting the huge elm_genlist calls. > > > > hint: I created eina_accessor to help with such thing. > > > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -- > > MSN: barbi...@gmail.com > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > > > > -- > brian > -- > > Cool-Karaoke - The smallest recording studio, in your palm, open-sourced > http://cool-idea.com.tw/ > > iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe > > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > ___ > 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 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Fri, 22 Jan 2010 10:15:52 +0800 Brian Wang said: > On Fri, Jan 22, 2010 at 9:28 AM, Carsten Haitzler > wrote: > > On Fri, 22 Jan 2010 09:15:44 +0800 Brian Wang > > said: > > > >> [snip] > >> > > >> > And to say more, just like I did with Guarana's list, we should > >> > abstract the model it uses, providing functions to check the number of > >> > items and get items given its index. That way we can write those > >> > functions that query SQL and no need to actually create a list with > >> > 1000 elements in order to show it. > >> > >> I'm not an expert of this, so bear with me. :-) > >> You mean saving items into an SQL database and SELECT them on demand? > >> If the database is on a disk (not RAM), wouldn't it be slow when the > >> list is scrolled around due to the querying? If the database is in > >> RAM, how is it different from the current implementation in terms of > >> memory footprint? > > > > thats what genlist does now - it doesnt select itself - you provide the > > callbacks in your item class as to how to get the data. it's up to you how > > to do thats > > > > what is different is there is an add stage. you add all the items (as each > > item can be a different class - ie style or content). the only differencce > > between what genlist does now and what gustavo is proposing is - who calls > > the adds. > > > > genlist needs to know what to call for each item to get its content - and > > what style to display it in. as such there is no way to do this without > > first telling genlist which items are of what type. > > > > ONLY in the case where all items are of the same size (regular grid) can you > > take possible shortcuts and just get item count and thus determine list > > height from my previous mail - width needs to also then be fixed. > > Yes. Homogeneous mode also implies 'compress' mode to limit the width > to its container. ok. as long as thats understood :) > > you are creating a very special-case list. genlist is genlist.. because > > its.. generic. it can handle anything you throw at it. every item can be a > > different style, and different size. genlist has its own deferred queue for > > adding items that it processes in idle time to keep it "fast" > > > > i'm not sure about what brian says - that the app becomes unresponsive. i've > > run this on lower-end arm's (armv6 - 800mhz - yes thats lower end these > > days!) and it runs just danndily on my test case with 2000, 1 or more > > items. it takes a while to populate the list, but u can scroll around and > > do things. > > By unresponsive, I mean that the scrolling becomes stuttering. Well, actual > aah yes. it might indeed as its devoting a portion of your cpu to evaluating all the items in the queue to be added. as such it might be an idea that it would be time limited not item # limited per idle loop. > I'm running it on a "lower-end" arm with 64MB of DDR. What I could > think of the difference other than the computing power is that my list > contains Chinese characters. I reason that freetype tends to render > Chinese charset slower due to the fact that the huge range of Chinese > character set does not fit into a reasonable-sized font cache. And of well actually evas will keep glyphs for all chars it has seen. its just unreferenced fonts (that hold the rendered glyphs) that are in cache. referenced fonts are all active data - as are all their glyphs. :) but - decoding the utf8 for chinese will cot more and glyphs will not be as nice on cpu caches. :) > course, armv6 vs armv5te, CPU core speed, DDR (I assume it's on your > target too) bus speed (mine is 133/266 with 16-bit data bus...) all armv6 is better indeed - though these days its all about cortex-a8 - even that is "not so hot" as ll the focus for new high-end is on cortex-a9 dual core babies. > make big difference. However, it's the difficulty of life that I have > to cope with. :-) better hardware fiixes oh so many problems :) > > > >> > This abstraction would also make it easier for python and other > >> > bindings, as it would be possible to walk "native" (python, perl...) > >> > without actually converting the huge elm_genlist calls. > >> > > >> > hint: I created eina_accessor to help with such thing. > >> > > >> > > >> > -- > >> > Gustavo Sverzut Barbieri > >> > http://profusion.mobi embedded systems > >> > -- > >> > MSN: barbi...@gmail.com > >> > Skype: gsbarbieri > >> > Mobile: +55 (19) 9225-2202 > >> > > >> > >> > >> > >> -- > >> brian > >> -- > >> > >> Cool-Karaoke - The smallest recording studio, in your palm, open-sourced > >> http://cool-idea.com.tw/ > >> > >> iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe > >> > >> -- > >> Throughout its 18-year history, RSA Conference consistently attracts the > >> world's best and brightest in the field, creating opportunities for > >> Conference attendees to learn
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Fri, Jan 22, 2010 at 10:36 AM, Carsten Haitzler wrote: > On Fri, 22 Jan 2010 10:15:52 +0800 Brian Wang > said: > >> On Fri, Jan 22, 2010 at 9:28 AM, Carsten Haitzler >> wrote: >> > On Fri, 22 Jan 2010 09:15:44 +0800 Brian Wang >> > said: >> > >> >> [snip] >> >> > >> >> > And to say more, just like I did with Guarana's list, we should >> >> > abstract the model it uses, providing functions to check the number of >> >> > items and get items given its index. That way we can write those >> >> > functions that query SQL and no need to actually create a list with >> >> > 1000 elements in order to show it. >> >> >> >> I'm not an expert of this, so bear with me. :-) >> >> You mean saving items into an SQL database and SELECT them on demand? >> >> If the database is on a disk (not RAM), wouldn't it be slow when the >> >> list is scrolled around due to the querying? If the database is in >> >> RAM, how is it different from the current implementation in terms of >> >> memory footprint? >> > >> > thats what genlist does now - it doesnt select itself - you provide the >> > callbacks in your item class as to how to get the data. it's up to you how >> > to do thats >> > >> > what is different is there is an add stage. you add all the items (as each >> > item can be a different class - ie style or content). the only differencce >> > between what genlist does now and what gustavo is proposing is - who calls >> > the adds. >> > >> > genlist needs to know what to call for each item to get its content - and >> > what style to display it in. as such there is no way to do this without >> > first telling genlist which items are of what type. >> > >> > ONLY in the case where all items are of the same size (regular grid) can >> > you >> > take possible shortcuts and just get item count and thus determine list >> > height from my previous mail - width needs to also then be fixed. >> >> Yes. Homogeneous mode also implies 'compress' mode to limit the width >> to its container. > > ok. as long as thats understood :) > >> > you are creating a very special-case list. genlist is genlist.. because >> > its.. generic. it can handle anything you throw at it. every item can be a >> > different style, and different size. genlist has its own deferred queue for >> > adding items that it processes in idle time to keep it "fast" >> > >> > i'm not sure about what brian says - that the app becomes unresponsive. >> > i've >> > run this on lower-end arm's (armv6 - 800mhz - yes thats lower end these >> > days!) and it runs just danndily on my test case with 2000, 1 or more >> > items. it takes a while to populate the list, but u can scroll around and >> > do things. >> >> By unresponsive, I mean that the scrolling becomes stuttering. Well, actual >> > > aah yes. it might indeed as its devoting a portion of your cpu to evaluating > all the items in the queue to be added. as such it might be an idea that it > would be time limited not item # limited per idle loop. Cool! That's why I'm limiting the max number of items within an item block to 1. But this figure will vary from platform to platform, thus requires tuning by the programmer. Time-limited loop in the idler sounds like a much better and correct implementation! > >> I'm running it on a "lower-end" arm with 64MB of DDR. What I could >> think of the difference other than the computing power is that my list >> contains Chinese characters. I reason that freetype tends to render >> Chinese charset slower due to the fact that the huge range of Chinese >> character set does not fit into a reasonable-sized font cache. And of > > well actually evas will keep glyphs for all chars it has seen. its just > unreferenced fonts (that hold the rendered glyphs) that are in cache. > referenced fonts are all active data - as are all their glyphs. :) but - > decoding the utf8 for chinese will cot more and glyphs will not be as nice on > cpu caches. :) > >> course, armv6 vs armv5te, CPU core speed, DDR (I assume it's on your >> target too) bus speed (mine is 133/266 with 16-bit data bus...) all > > armv6 is better indeed - though these days its all about cortex-a8 - even that > is "not so hot" as ll the focus for new high-end is on cortex-a9 dual core > babies. > >> make big difference. However, it's the difficulty of life that I have >> to cope with. :-) > > better hardware fiixes oh so many problems :) It's always about the cost though. :-) > >> > >> >> > This abstraction would also make it easier for python and other >> >> > bindings, as it would be possible to walk "native" (python, perl...) >> >> > without actually converting the huge elm_genlist calls. >> >> > >> >> > hint: I created eina_accessor to help with such thing. >> >> > >> >> > >> >> > -- >> >> > Gustavo Sverzut Barbieri >> >> > http://profusion.mobi embedded systems >> >> > -- >> >> > MSN: barbi...@gmail.com >> >> > Skype: gsbarbieri >> >> > Mobile: +55 (19) 9225-2202 >> >> > >> >> >>
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
Am 22.01.2010 um 02:15 schrieb Brian Wang: > [snip] >> >> And to say more, just like I did with Guarana's list, we should >> abstract the model it uses, providing functions to check the number of >> items and get items given its index. That way we can write those >> functions that query SQL and no need to actually create a list with >> 1000 elements in order to show it. > > I'm not an expert of this, so bear with me. :-) > You mean saving items into an SQL database and SELECT them on demand? > If the database is on a disk (not RAM), wouldn't it be slow when the > list is scrolled around due to the querying? If the database is in > RAM, how is it different from the current implementation in terms of > memory footprint? It's very different, as you can apply several interesting tricks like paging and caching (i.e. only loading what will actually shown, grabbing 20 or 30 per SQL request etc.) and -- if you have the proper infrastructure -- cancelling requests for items that have already been scrolled out of the visible area. :M: -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm_genlist Performance Problem Revisited (Loading and Scrolling)
On Fri, 22 Jan 2010 11:03:05 +0800 Brian Wang said: > On Fri, Jan 22, 2010 at 10:36 AM, Carsten Haitzler > wrote: > > On Fri, 22 Jan 2010 10:15:52 +0800 Brian Wang > > said: > > > >> On Fri, Jan 22, 2010 at 9:28 AM, Carsten Haitzler > >> wrote: > >> > On Fri, 22 Jan 2010 09:15:44 +0800 Brian Wang > >> > said: > >> > > >> >> [snip] > >> >> > > >> >> > And to say more, just like I did with Guarana's list, we should > >> >> > abstract the model it uses, providing functions to check the number of > >> >> > items and get items given its index. That way we can write those > >> >> > functions that query SQL and no need to actually create a list with > >> >> > 1000 elements in order to show it. > >> >> > >> >> I'm not an expert of this, so bear with me. :-) > >> >> You mean saving items into an SQL database and SELECT them on demand? > >> >> If the database is on a disk (not RAM), wouldn't it be slow when the > >> >> list is scrolled around due to the querying? If the database is in > >> >> RAM, how is it different from the current implementation in terms of > >> >> memory footprint? > >> > > >> > thats what genlist does now - it doesnt select itself - you provide the > >> > callbacks in your item class as to how to get the data. it's up to you > >> > how to do thats > >> > > >> > what is different is there is an add stage. you add all the items (as > >> > each item can be a different class - ie style or content). the only > >> > differencce between what genlist does now and what gustavo is proposing > >> > is - who calls the adds. > >> > > >> > genlist needs to know what to call for each item to get its content - > >> > and what style to display it in. as such there is no way to do this > >> > without first telling genlist which items are of what type. > >> > > >> > ONLY in the case where all items are of the same size (regular grid) can > >> > you take possible shortcuts and just get item count and thus determine > >> > list height from my previous mail - width needs to also then be fixed. > >> > >> Yes. Homogeneous mode also implies 'compress' mode to limit the width > >> to its container. > > > > ok. as long as thats understood :) > > > >> > you are creating a very special-case list. genlist is genlist.. because > >> > its.. generic. it can handle anything you throw at it. every item can be > >> > a different style, and different size. genlist has its own deferred > >> > queue for adding items that it processes in idle time to keep it "fast" > >> > > >> > i'm not sure about what brian says - that the app becomes unresponsive. > >> > i've run this on lower-end arm's (armv6 - 800mhz - yes thats lower end > >> > these days!) and it runs just danndily on my test case with 2000, 1 > >> > or more items. it takes a while to populate the list, but u can scroll > >> > around and do things. > >> > >> By unresponsive, I mean that the scrolling becomes stuttering. Well, > >> actual > >> > > > > aah yes. it might indeed as its devoting a portion of your cpu to evaluating > > all the items in the queue to be added. as such it might be an idea that it > > would be time limited not item # limited per idle loop. > > Cool! That's why I'm limiting the max number of items within an item > block to 1. But this figure will vary from platform to platform, thus > requires tuning by the programmer. Time-limited loop in the idler > sounds like a much better and correct implementation! warning. this has other consequences. if you have a lot of items - this means when scrolling it has to walk EVERY block - now u have as many blocks as there are items. have 5000 items and it literally walks a linked list of 5000 blocks checking to see if the blocks are "in or out of view" and realizes/unrealises items. as such this is useful as you can adjust block size now based on expected content size - good as you can limit the # of blocks to walk and compromise with more objects existing to move during scrolling. yes - i didnt have time, but nicer would be a tree. blocks, super blocks, jumbo-blocks etc. (super block is a collection of N blocks, jumbo block is a collection of N superblocks etc.) and it can keep track of the geometry of the super/jumbo block like it does with blocks (and propagate up to the parents when geometry changes), and that would avoid walking every block while scrolling, but i never got there. it's an optimisation yet to be done. :) > >> I'm running it on a "lower-end" arm with 64MB of DDR. What I could > >> think of the difference other than the computing power is that my list > >> contains Chinese characters. I reason that freetype tends to render > >> Chinese charset slower due to the fact that the huge range of Chinese > >> character set does not fit into a reasonable-sized font cache. And of > > > > well actually evas will keep glyphs for all chars it has seen. its just > > unreferenced fonts (that hold the rendered glyphs) that are in cache. > > referenced fonts are all active data - as are all t
