I'm very happy to announce that I've been accepted for this year's Google Summer of Code program! The full list of participants within OSGeo can be found here.

My proposal aims to improve speed and responsiveness of Quantum GIS when doing commonly used operations such as map browsing. This should be achieved by adding threading support to the process of rendering and by optimizing related routines. The user interface should feel snappy even when browsing large datasets.

Read on for the proposal details.

Introduction

Desktop GIS software, like other desktop software, is aimed at users and therefore it should be easy to use, responsive and fast. Using applications with obscure user interface is a pain, so it is if applications need long time for doing simple operations. It is however hard to say what being slow (or fast) really means in terms of software. My opinion is that operations that inherently do _not_ need a lot of processing time (due to the amount of data / complexity of the algorithm) should be (nearly) instant. Slower operations that can take few seconds or more shouldn't freeze the application and give some indicator that something is going on (preferably with an estimate how long it will take).

Quantum GIS (QGIS) has a good user interface, however certainly there are possibilities to make the typical usage feel faster. By the typical usage I mean mainly browsing (zooming, panning) of the vector and raster layers in map canvas. Currently, when you zoom or pan, QGIS starts rendering and you have to wait until it finishes (or hit Esc key to stop it). When working with larger datasets, it is daunting to wait few seconds on every operation.

The situation can be approached on several fronts: optimize code to run faster, better inform users if the processing is underway and finally use parallelism for tasks that can be divided into smaller ones.

The idea

The project can be viewed as a combination of orthogonal targets:

1. Introduce parallelism into rendering: as of now, rendering of map layers is done serially in one single (gui) thread. Nowadays processors with more cores are pretty common, so this is an obvious target for improvements: split the rendering into several threads to use the full power of processor. QtConcurrent framework (shipped with Qt >= 4.4) should be helpful here - it implements map-reduce and few other patterns, documentation claims it scales automatically on available cores.
2. Improve user experience when browsing map: move from the traditional model (where map is first rendered, then user zooms/pans) to a modern approach used in web mapping: user freely zooms and pans the map which is continuously updated. This means that rendering should be controlled from a separate thread and only post updated pieces of rendered map to the main thread. Here the things can get a bit hairy: for example, a layer is being iterated within rendering thread, in meanwhile user opens attribute table which will try to iterate over the same layer. We need to improve the API of map layers that will provide thread-safe access to the underlying data. The mechanism has to serialize access to data from various threads using synchronization primitives if the data provider is not thread-safe. An advanced solution would be to make important data providers thread-safe without serialization of access.
3. Optimization of map rendering: first, the rendering pipeline should be benchmarked on various datasources, the bottlenecks should be identified and some improvements should be proposed. After a discussion with mentor, proposals promising good speed ups with feasible scope should be implemented. I'd like to develop simple tests that will allow to focus the benchmarking on the rendering process. I expect to use profiling tools like callgrind and sysprof, for i/o profiling strace can be used.
4. Miscellaneous optimizations: if time allows, some additional improvements to speed or user experience can be done. This could be e.g. lowering QGIS startup time, addition of caching of features from vector layers, improvements to startup of attribute table (indicator of loading, caching) and others. I would consider this part optional.

Finally, we should end up with QGIS that is both faster and more pleasant to work with :-)

Project plan

First week I'll have to do final exams and defend my master thesis - I will start coding one week later.

Rough estimate of the work plan:

1. (parallel rendering) 1 week
2. (better map browsing) 4 weeks
3. (optimized rendering) 3 weeks
4. (misc optimizations) 3 weeks

I'd like to have the point #2 ready at the time of mid-term evaluations.

Future ideas / How can your idea be expanded?

Software can be always optimized a bit more. It's likely that during the SoC I will encounter some performance issues that would require a lot of time. Such issues will be written down so in future someone can pick them up and implement. Moreover, there's a possibility that some bottlenecks will be found in underlying libraries, these can be fixed and all projects that use them will benefit from the improvements.