Week 31/2013: 1.11.1 released, autocompletion popup
Last week we released 1.11.1 and I was working on client UI improvements.
There are more details about the 1.11.1 patch in the news post.
During the week I made several improvements to the behavior of the console command line autocompletion. Now when you press Tab and there are multiple alternative completions, you will get a popup listing all the possible ones:
While implementing this it became apparent that there were a number of performance issues in getting a longer piece of text prepared for drawing. As a first step, I used a background thread for preprocessing text so that the UI is not blocked. (I must say that thanks to the Task/TaskPool classes in libdeng2, it is now quite easy indeed to run operations in background threads.) I also did some profiling to see what was really going on, and found that the text wrapper was spending most of its time on completely unnecessary memory copying. Some refactoring yielded an order of magnitude improvement in its performance.
So in other words, text-related UI performance is now improved.
While working on the popup, I also got stumped by a weird layout bug. Eventually I found the source of the problem. The Rule system I developed for UI layout has proven its worth, but debugging it is somewhat tricky. Fortunately, it's starting to look quite bug-free now (knocks on wood).
Another UI related step forward was to get rid of the old code for drawing the busy mode progress indicator. This is the rotating gear that is displayed when starting Doomsday or loading a game/map. Now the new UI framework is responsible for this UI element. This has made it possible to use the same indicator elsewhere in the UI, for instance in the autocompletion popup when preparing a long list of completions.
My plan is to continue revamping old UI elements so that the Control Panel, autoupdater, and multiplayer setup can be handled by new widgets.
There are more details about the 1.11.1 patch in the news post.
During the week I made several improvements to the behavior of the console command line autocompletion. Now when you press Tab and there are multiple alternative completions, you will get a popup listing all the possible ones:
While implementing this it became apparent that there were a number of performance issues in getting a longer piece of text prepared for drawing. As a first step, I used a background thread for preprocessing text so that the UI is not blocked. (I must say that thanks to the Task/TaskPool classes in libdeng2, it is now quite easy indeed to run operations in background threads.) I also did some profiling to see what was really going on, and found that the text wrapper was spending most of its time on completely unnecessary memory copying. Some refactoring yielded an order of magnitude improvement in its performance.
So in other words, text-related UI performance is now improved.
While working on the popup, I also got stumped by a weird layout bug. Eventually I found the source of the problem. The Rule system I developed for UI layout has proven its worth, but debugging it is somewhat tricky. Fortunately, it's starting to look quite bug-free now (knocks on wood).
Another UI related step forward was to get rid of the old code for drawing the busy mode progress indicator. This is the rotating gear that is displayed when starting Doomsday or loading a game/map. Now the new UI framework is responsible for this UI element. This has made it possible to use the same indicator elsewhere in the UI, for instance in the autocompletion popup when preparing a long list of completions.
My plan is to continue revamping old UI elements so that the Control Panel, autoupdater, and multiplayer setup can be handled by new widgets.
Comments
With the 1.11 release many of you will have noticed a large drop in performance as far as loading and (particularly) unloading very large maps. This came about due to a fundamental change in the way we manage memory for maps and how this conflicted with the management of data for the bias lighting model.
Prior to the release I began a new work branch to address these issues. However, as we were already in mid candidate phase and the scale of the changes being somewhat large we decided against merging this work for the 1.11 release.
This branch has now been merged and is present in Build947.
So what does this mean? Firstly, memory management for the bias lighting model has now been completely redesigned. Where previously we'd always allocate storage for this irrespective of whether bias lighting was enabled, this is no longer the case with this data now prepared just in time for rendering (but only if this lighting model is in use). I took the opportunity to rethink the implementation and following various refactorings arrived at a scheme that uses significantly less memory for the exact same functionality. In the process obsoleting the old, slow bookkeeping algorithms. Consequently map (un)load performance is now as good if not better than it was previously.
Secondly, this work sees the introduction of a couple of "new" architectural concepts for runtime map editing which will be important in the future. Specifically we now have a generic "hand plus grabbables" mechanism, which, facilitates user interaction with elements of the map. In the short term, however, the immediate benefits can be seen in the bias lighting editor, which now allows one to manipulate multiple light sources at once (e.g., grabbing several lights and moving them all as a "unit").
With these issues now addressed I intend to return to working on the map data improvements ahead of the 2.0 map renderer. In particular my plan for the coming week(s) is to focus on improving map hack support.