From: N-Billy <n-...@gm...> - 2009-06-28 15:30:51
Attachments:
testcode.svndiff
|
Hello e-developers, I'm working on the enna project and found a bug within the elementary library. The error occurs using the generic list when scrolling. As far as I was able to analyse, the list is organized with blocks of max 32 items. Now, when selecting an item within a block other than the first item of that block, the wrong region is scrolled to. Thus the selected item is not visible. I've modified the elementary_test a bit to reproduce this by generating a long list (2000 items), with three jumps (selections) each after 5 seconds. The first one jumps to item 38, so the 6th item of the second block. This won't work, instead the region of items 43 to 52 is shown. The second jump is to item 32 which works fine and shows that item on the top of the visible area. The third jump again to item 38 will work too as the block seems to be correctly 'initialized' now. There's also some debugging output showing that the coordinates of the same item within the list changes (y from 780 to 240). Interestingly when setting the whole window hight to 800px everything works fine. But e.g. with 400px it's reproducable. Attached you'll find the patch for that test. Just start the first "Genlist" example to reproduce. I just used the latest revision from repository. Bill |
From: N-Billy <n-...@gm...> - 2009-08-05 17:00:29
|
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); } On 06/28/2009 05:15 PM, N-Billy wrote: > Hello e-developers, > > I'm working on the enna project and found a bug within the elementary > library. The error occurs using the generic list when scrolling. > As far as I was able to analyse, the list is organized with blocks of > max 32 items. Now, when selecting an item within a block other than > the first item of that block, the wrong region is scrolled to. Thus > the selected item is not visible. > I've modified the elementary_test a bit to reproduce this by > generating a long list (2000 items), with three jumps (selections) > each after 5 seconds. The first one jumps to item 38, so the 6th item > of the second block. This won't work, instead the region of items 43 > to 52 is shown. The second jump is to item 32 which works fine and > shows that item on the top of the visible area. The third jump again > to item 38 will work too as the block seems to be correctly > 'initialized' now. > There's also some debugging output showing that the coordinates of the > same item within the list changes (y from 780 to 240). > Interestingly when setting the whole window hight to 800px everything > works fine. But e.g. with 400px it's reproducable. > > Attached you'll find the patch for that test. Just start the first > "Genlist" example to reproduce. > > I just used the latest revision from repository. > > Bill |
From: Gustavo S. B. <bar...@pr...> - 2009-08-05 17:30:00
|
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. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
From: N-Billy <n-...@gm...> - 2009-08-05 18:30:23
|
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 :( |
From: Carsten H. (T. R. <ra...@ra...> - 2009-09-04 16:05:44
|
On Wed, 05 Aug 2009 20:07:26 +0200 N-Billy <n-...@gm...> said: > 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 :( fixed. genlist happend to mis-calc at one point but on placing the items it calcs them correctly. fixed. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Gustavo S. B. <bar...@pr...> - 2009-08-05 18:53:11
|
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. 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. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: bar...@gm... Skype: gsbarbieri Mobile: +55 (19) 9225-2202 |
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 :-) |