Neil's Place

October 24, 2009

Command Updating Performance

Filed under: Uncategorized — enndeakin @ 2:13 pm

This week, I’ve been investigating how to improve command handling in XUL, both in terms of manner they’re used and particularly, performance. Command handling is what deals with performing actions in response to menu or keypresses. There are several types of commands. The first are those like cut and paste that typically appear on menus, where the bulk of the handling deals with ensuring that the menus, toolbar buttons and actions are enabled and disabled at the right time. The second are input field cursor and selection commands (such as move to next word, page down, etc). Mozilla cheats a bit and doesn’t check if they should be enabled as they don’t normally have UI that shows this. The third are complex edit commands such as bold, font changes and so forth. These are similar to the first set really. As an aside, it would be quite nice to be handle all of these in a similar fashion.

For whatever reason, most of the handling is done in C++ with a small amount of code done in script. In many cases, though the script is unnecessary. For example, a typical cut command looks like the following:

<command id=”cmd_cut” oncommand=”goDoCommand(‘cmd_cut’)”/>

This is quite pointless as the act of ‘do’ing the command should just be the default behaviour.

Updating command state is another issue and one which can be quite slow. In fact, a workaround was added just to improve performance due to this. Updating command state refers to the process of updating the UI when the focus or selection changes to reflect which commands are now enabled. For example, a cut operation is only valid when there is text selected.

Here’s an overview of how the update process breaks down in time used:

Fire commandupdate event at updaters: 17%
Retrieve the topmost window: 14%
Retrieve the command dispatcher: 8%
Retrieve the right controller: 33%
Checking if the command is enabled: 15%
Set disabled attribute on command elements: 13%

I was expecting the latter two steps to be the bulk of the time used, but this wasn’t the case. This was a good sign since the other steps are easier to optimize away. One particular issue is that, except for the first step, the remaining steps occur again and again for every command that needs to be updated, which includes additional time due to calling into Javascript and back several times.

Instead, by optimizing to perform the repeated steps only once, as well as not calling into Javascript unnecessarily we can reduce the amount of time taken up. Most of the time, the script just calls back to update each command in the same way every time much like goDoCommand is called in the earlier example, so this is also a bit silly.

I created a simple performance test which updates the typical eight edit-related commands one thousand times. With current code, the test took over 625 milliseconds to complete (which means about half a millisecond each). This isn’t much individually, but might be noticeable if lots of commands were being updated.

I created a simple implementation of the changes described above, still a work in progress, and have reduced this to about 60 milliseconds to update one thousand times. This is a speedup of over 10 times.

I have also been experimenting with caching the list of commands and their disabled state, rather than setting a disabled attribute on the command elements. This can improve the time to 40 milliseconds. One advantage to this is that it could mean that the command element isn’t needed for many commands — if we cache the disabled state internally, in many cases we don’t really need the command element any more.

In many cases, the UI for commands such as undo isn’t actually visible until the Edit menu is opened. Using some smart caching, we can make the work of updating these commands only occur when the menu is opened. This already happens to some degree, but much additional and extraneous work is done upfront rather than later.

Next, I’m going to investigate some of the other types of commands and further see how a smart command caching mechanism might work.


October 5, 2009

Visible Focus Rings

Filed under: Uncategorized — enndeakin @ 3:59 pm

Platforms differ in the way that they show which element is focused. So does Firefox, which differs in a number of ways from platform conventions.

The typical way is to draw either a glow or dotted outline around a button or input field that accepts keyboard entry. However, this behaviour can sometimes cause unwanted visible display or bad interactions when the keyboard is not being used. For instance, when clicking a link on a page, the behaviour is to draw a visible dotted outline around the link, then load the next page. This is useful to know that the link has been clicked, but causes an unnecessary outline that can disrupt the appearance, especially if the link is an image or part of an image map.

One significant advantage of showing the link however, is that when going back to a page, one can immediately see where the keyboard focus is, and for non-keyboard use, indicates clearly which link was clicked, a useful indicator when visiting a series of links in succession.

Another behaviour is that, especially on Mac, various elements don’t switch the focus when clicking on them. For instance, clicking a checkbox in a dialog box or selecting from a dropdown list doesn’t change which element is focused. In this image, the first dropdown has a visible focus indicator (a blue glow around it), but clicking the later dropdown has not changed this.

On Windows, what used to be the norm is to show dotted outlines around focused elements, and show underlines under letters of the labels of controls or menus to indicate a key which can be used to focus or activate it. In today’s versions of Windows, though, that behaviour isn’t used, although it can be enabled through a system setting. Instead, these indicators are only visible once the user presses a key. For instance, pressing Alt shows the menu label indicators, as well as shows a visible focus ring around the element that accepts keyboard input. Tabbing to an element does similar.

The goal of bug 418521 is to improve the situations described above in Mozilla to be more compatible with how the system behaves. Followup bugs will address additional issues with specific controls. More specifically, this means:

On Windows, don’t show indicators at all until the user uses the keyboard to access an element. But, respect the system setting if the user wants them visible at all times.

On Mac, don’t focus elements when clicking on them, except for lists and text input fields.

On Linux, always show indicators. This is the current behaviour so Linux users won’t notice changes from this bug.

One change of note on all platforms is that links will no longer show the dotted focus outline when they are clicked, whether they are image links or otherwise. However, the dotted outline will be made visible when navigating back to the page, or when switching tabs back to that page. This solves the issue of not adding visible noise to the page in normal usage, but doesn’t prevent the user from seeing which link was clicked when going back to that page again.

For this change to be effective, a new css pseudoclass is proposed, to accompany the existing :focus pseudoclass.

The :focus pseudoclass will continue to work as it does now. If will match any element which is focused. However, the new pseudoclass :-moz-focusring will only match when the element is focused and the focus indicator should be shown. So if you are creating a theme for instance, the :-moz-focusring pseudoclass should be used to show focus indicators as this deals with all of the platform specific details. For example:

button:-moz-focusring {
  outline: 1px dotted black;

For details of the changes see comment 57 in the bug.

Create a free website or blog at