PDA

View Full Version : [4.2.3] Faster button creation



Werzi2001
5 May 2015, 1:09 AM
Hello,

i am creating an application that has the need of updating a toolbar at very frequent intervals. This includes clearing and recreating (in a different way depending on current state of application) all buttons within the toolbar.

Currently that takes about 200ms which is to much. The time is needed only for the rendering (suspendLayouts, remove all buttons, add all buttons, resumeLayouts). It does not include getting the needed information to determine which buttons to create.

Is there any way to speed that up? For example some kind of lightweight button?

Thanks for your help.
Thomas

yeghikyan
5 May 2015, 1:45 AM
try to play with resumeEvents and suspendEvents of the toolbar.

Werzi2001
5 May 2015, 2:34 AM
Thanks for your advice but add suspendEvents(true) and resumeEvents didn't change much (maybe 5-10ms).

skirtle
5 May 2015, 3:54 AM
Is the time spent rendering or doing the layouts? If it's the latter then a lightweight button may not help but a few tweaks to your layout config (e.g. fixed sizes on the toolbar) might.

I suggest running this through a profiler in your browser of choice (or even better, multiple browsers) to get a clear idea of exactly where the time is spent.

yeghikyan
5 May 2015, 4:37 AM
There is also another solution, you can have this buttons and rename only the text label... of coutrse the toolbar must have max number of buttons and unused buttons must be hidden. A little bit tricky, but works.

Werzi2001
5 May 2015, 6:07 AM
Thanks for your replies.

@skirtle: Could you give me some more information about what i could tweak if the layout is the problem? It's probably easier to just try that then doing the profiling as it is not possible to separate the toolbar from the rest and i would probably not get any useful results.

@yeghikyan: I don't think i can use dummy buttons and just replace the text as not only the text changes but also the menu, click listener of course and a few further things.

skirtle
5 May 2015, 6:31 AM
@skirtle: Could you give me some more information about what i could tweak if the layout is the problem? It's probably easier to just try that then doing the profiling as it is not possible to separate the toolbar from the rest and i would probably not get any useful results.

You must get some decent measurements on this before you start making changes. It isn't necessary to isolate the toolbar changes, quite the opposite, the measurements are only meaningful in the context of everything else. You don't need a detailed breakdown, just establish whether it is rendering or layout that is the problem. Even just timing resumeLayouts would be a guide.

As I already mentioned, the sorts of tweaks involved would be things like fixed sizes on the toolbar. e.g. height: 32. The reason for this is that your toolbar is (possibly) determining its height based on its child items, so any change to the child items needs the toolbar to recalculate its size. That in turn can trigger further layouts up the container hierarchy as the toolbar height has 'changed' (it doesn't matter if it hasn't changed in practice, just the potential for change is enough).

A small change to a single button, even just updating the text, can potentially trigger layouts for every component on your page if the layout configs don't allow any isolation. The key concept here is the 'layout root', which is the first container up the hierarchy that can run its layout without needing to ask its parent for help.