From: N-Billy <n-...@gm...> - 2009-08-06 20:00:30
|
On 08/05/2009 08:52 PM, Gustavo Sverzut Barbieri wrote: > On Wed, Aug 5, 2009 at 3:07 PM, N-Billy<n-...@gm...> wrote: > >> On 08/05/2009 07:29 PM, Gustavo Sverzut Barbieri wrote: >> >> On Wed, Aug 5, 2009 at 1:48 PM, N-Billy<n-...@gm...> wrote: >> >> >> now I finally found a way to fix this, though I'm sure it's rather a >> workaround than a fix. >> >> the problem seems to be that evas has to render in order to correct the >> coordinates of the buttons within the block. Thus, enforcing evas_render >> and adjusting the scroller again works fine. >> Could pls s.o. look into that issue? I assume this render operation >> should be placed somewhere else, but I dunno where. Just calling it >> before adjusting the scroller region doesn't work. >> >> >> Index: src/lib/elm_genlist.c >> =================================================================== >> --- src/lib/elm_genlist.c (revision 41609) >> +++ src/lib/elm_genlist.c (working copy) >> @@ -1902,6 +1902,11 @@ >> it->x + it->block->x, >> it->y + it->block->y, >> it->block->w, it->h); >> + evas_render(evas_object_evas_get(it->wd->obj)); >> + elm_smart_scroller_child_region_show(it->wd->scr, >> + it->x + it->block->x, >> + it->y + it->block->y, >> + it->block->w, it->h); >> } >> >> >> I have not followed this thread in depth or investigated the problem, >> but this is wrong. You should never force evas to render at any time, >> this is bad. >> >> >> >> Hi Gustavo, >> >> just found out that even this helps only for the second block. Testing with >> items>100 shows this doesn't help fully. >> I just investigated when the coordinates it->y change from wrong to correct >> and it was on idle/main loop. So I tried to force by rendering and it helped >> at least a bit. >> >> Something's wrong with the recalculation and maybe the >> elm_smart_scroller_child_region_show should then be added as a job or s.th. >> to be done asynchronously as well? >> >> This bug is annoying but I still cannot find a proper solution :( >> > > You'll need raster to look at it, he wrote it so he might know. > hm, hope he reads this in here :-) > I'm still pending elementary refactor (aka merge with guarana) and > then port my own list implementation. It's faster than genlist and > orders of magnitude simpler than genlist, but comes with some > limitations: you need the same row renderer for all rows, they should > be of fixed size and now tree support. These limitations make it much > simpler as we can keep a fixed pool of visible objects + 2 (spare) and > recycle them, show a given region is basic math + move. I don't know > your use case, but for things like music players and directory listing > it should do. > > sound like this would be sufficient, since the use case actually is only a list of files, no tree. should be worth a try :-) |