08-12-2012 04:06 AM
I have a custom tablelayoutmanager. I have overridden the navigation movement and paint methods.
In paint, i am painting the selected row.ie.row with the focused field a different color and the actual focused field a different color.
Now, when the table has around 50 rows, the vertical scrolling is very fast. But when the rows are something like
250 rows, the vertical scroll drastically slows down especially when at the boundaries.
Well at first i thought its just because of the colossal amount of data that is to be displayed. But looking at apps like
Twitter or facebook which have lots more data, and still seem to have lighning smooth scroll, i realized i had to be missing something.
I have tried everything i could think of. Please help.
Solved! Go to Solution.
08-12-2012 05:51 AM
I would assume that the issue is straight CPU, since I believe you already have the data and you are not updating the Manager as you are scrolling. Let us know if this is not correct.
I recommend using the profiler
to determine where the CPU is being used.
Most likely it is in your paint() routine, and given you say it works fine with 50, you should look for processing in there that will increase with the number of elements, for example, a search of the elements. But the profiler should help you find these places.
Let us know how you get on.
08-12-2012 03:31 PM
Apolgoies, I thought that was Eclipse.
You will find the Sarch box very useful for things like this.
08-13-2012 05:03 AM
" you are not updating the Manager as you are scrolling ". Can you please explain this? Would not deleting and adding fields to the manager on scroll further add to the CPU overhead?
08-13-2012 06:03 AM
I tjhink we are saying the same thing. Adding and deleting Fields while scrolling will add to the CPU overhead, possibly singificantly.
Note that I said I presume that "you are not updating the Manager as you are scrolling".
08-13-2012 06:10 AM
Ok. Is there a way of doing this using timer tasks. I found a different thread about this, but am not able to make sense of it.
08-13-2012 06:58 AM
Not sure, but I would explore the option of optimizing your code first rather than trying to implement a further confusing layer on your code.
So are you adding and removing Fields?
08-13-2012 08:09 AM - edited 08-13-2012 08:17 AM
Nope. Iam just populating the table once in the screen constructor.
Actually, iam not sure if we really need to do the adding and removing.
I looked at the paint method of the screen class and it says "Paints this screen's visible region". So, if API is to be believed, the os only paints the visible fields. So a field outside the visible screen will not be painted and should not consume memory.
And i think the problem may be the for loop i use in my paint method. I have max 10 field in a row, so 250 rows gives 2500 loops, which may be the cause.
Whenever the navigation movement happens within the visible screen, i use a different customised paint method.
But when scrolling happens on boundaries, the OS calls the default paint method with the for loop. and thats making the scroll slow. Is there a way to override this default behaviour.
08-13-2012 08:26 AM
I presume you are overriding paint in the Manager. The first question I would ask is why override paint for the Manager?
I suspect the standard managers actually figure out which Fields are on display and only paint these. I am not an expert on this, but I think the context region will give you the 'extent' of the paintable region and then you , in your Manager's paint routine could avoid painting things that are not on display.
But the question still remains, why do you need to override the paint?