diff options
Diffstat (limited to 'src/datavisualization/doc')
| -rw-r--r-- | src/datavisualization/doc/src/qtdatavisualization.qdoc | 44 |
1 files changed, 26 insertions, 18 deletions
diff --git a/src/datavisualization/doc/src/qtdatavisualization.qdoc b/src/datavisualization/doc/src/qtdatavisualization.qdoc index cdbd4e4b..c3196dee 100644 --- a/src/datavisualization/doc/src/qtdatavisualization.qdoc +++ b/src/datavisualization/doc/src/qtdatavisualization.qdoc @@ -238,9 +238,18 @@ and which role specifies the value of the item. When the proxy resolves the data from the model, it uses these mappings to generate the rows and columns of the bar graph. + Often the item models will have a single role that contains information you want to map to + multiple values. A typical example of this is a timestamp field when generating a bar graph + with two time related axes, for example years and months. To enable mapping a single item + model role to more than one data field, pattern matching and replacing mechanism is provided + by item model proxies. You can also use this mechanism to reformat data even in one-to-one + mapping cases. + Depending on the visualization type, proxies may support other functionalities as well, such as QItemModelBarDataProxy optionally mapping QAbstractItemModel rows and columns directly - into bar graph rows and columns. See individual proxy classes for more information and examples + into bar graph rows and columns. + + See individual proxy classes for more information and examples about how to use them: QItemModelBarDataProxy, QItemModelScatterDataProxy, and QItemModelSurfaceDataProxy. @@ -257,28 +266,27 @@ When you have a data set that updates rapidly, it is important to handle data properly to ensure good performance. Since memory allocation is a costly operation, always use - QList::reserve() and QVector::resize() where possible to avoid reallocations when constructing - the array to give to the proxy. If you need to change the entire data set for each frame, - it is in most cases best to reuse the existing array - especially if the array dimensions do not - change. If you need to add, insert, remove, or change several rows or items for each frame, it - is always more efficient to do it with one method call instead of multiple calls affecting - a single row or item each. For example, adding ten rows with a single QBarDataProxy::addRows() call - is much more efficient than ten separate QBarDataProxy::addRow() calls. - - Bars renderer is optimized to access only data that is within the data window and thus should not - suffer noticeable slowdown even if more data is continually added to the proxy. + QList::reserve() and QVector::resize() where possible to avoid unnecessary reallocations when + constructing the array to give to the proxy. If you need to change the entire data set + for each frame, it is in most cases best to reuse the existing array - especially if the + array dimensions do not change. If you need to add, insert, remove, or change several + rows or items for each frame, it is always more efficient to do it with one method call + instead of multiple calls affecting a single row or item each. For example, adding ten + rows with a single QBarDataProxy::addRows() call is much more efficient than ten + separate QBarDataProxy::addRow() calls. + + Bars renderer is optimized to access only data that is within the data window and thus + should not suffer noticeable slowdown even if more data is continually added to the proxy. Due to the unsorted nature of the scatter data, any change in the data window ranges requires all data points to be checked for visibility, which can cause increasing slowdown if data is - continually added to the proxy. + continually added to the proxy. For the best performance with the scatter graphs, only keep + the data you need in the proxy. Surface data, while on item level similar to scatter data, is already assigned into rows and - columns, so the surface renderer can do some optimization by making the assumption that the data in - rows and columns is sorted along their respective axes, but it is nowhere near as efficient - as in the bars case. Surface rendering can suffer significant slowdown if the data size grows unchecked. - - For the best performance with the scatter and surface graphs, only keep the data you need in the - proxy. + columns, so the surface renderer can optimize drawing by making the assumption that + the data in the rows and columns is sorted along their respective axes. It is not quite as + efficient as in the bars case, but nearly so. */ /*! |