Doc: language review

Change-Id: I551749d26b2a7aec246fe7d448e0cd4312f5c20f
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>

1 files changed, 34 insertions, 25 deletions

diff --git a/doc/src/qmlapp/performance.qdoc b/doc/src/qmlapp/performance.qdoc
index 7e10b123..87ea8d22 100644
--- a/doc/src/qmlapp/performance.qdoc
+++ b/doc/src/qmlapp/performance.qdoc
@@ -582,6 +582,16 @@ Also remember that you can avoid doing composition work at run-time by providing
 pre-composed image resource with your application (for example, providing elements with shadow
 effects).
 
+\section3 Avoid Smoothing Images
+
+Enable \c{image.smooth} only if required. It is slower on some hardware, and it has no visual
+effect if the image is displayed in its natural size.
+
+\section3 Painting
+
+Avoid painting the same area several times. Use Item as root element rather than Rectangle
+to avoid painting the background several times.
+
 \section2 Position Elements With Anchors
 
 It is more efficient to use anchors rather than bindings to position items
@@ -731,8 +741,7 @@ buffering of delegates outside of the visible area. Utilizing a \c cacheBuffer i
 recommended for view delegates that are non-trivial and unlikely to be created within a
 single frame.
 
-Be mindful that a \c cacheBuffer keeps additional delegates in-memory and therefore the
-value derived from utilizing the \c cacheBuffer must be balanced against additional memory
+Bear in mind that a \c cacheBuffer keeps additional delegates in-memory. Therefore, the value derived from utilizing the \c cacheBuffer must be balanced against additional memory
 usage. Developers should use benchmarking to find the best value for their use-case, since
 the increased memory pressure caused by utilizing a \c cacheBuffer can, in some rare cases,
 cause reduced frame rate when scrolling.
@@ -760,7 +769,7 @@ thread (and therefore can cause frames to be skipped if they take too long to co
 \section2 Particles
 
 The \l {QtQuick.Particles}{Qt Quick Particles} module allows beautiful particle effects to be integrated
-seamlessly into user interfaces. However every platform has different graphics hardware
+seamlessly into user interfaces. However, every platform has different graphics hardware
 capabilities, and the Particles module is unable to limit parameters to what your hardware
 can gracefully support. The more particles you attempt to render (and the larger they are),
 the faster your graphics hardware will need to be in order to render at 60 FPS. Affecting
@@ -881,8 +890,8 @@ memory will be allocated are very important considerations. Aside from the obvio
 concerns about out-of-memory conditions on memory-constrained devices, allocating memory
 on the heap is a fairly computationally expensive operation, and certain allocation
 strategies can result in increased fragmentation of data across pages. JavaScript uses
-a managed memory heap which is automatically garbage collected, and this provides some
-advantages but also has some important implications.
+a managed memory heap which is automatically garbage collected, and this has some
+advantages, but also some important implications.
 
 An application written in QML uses memory from both the C++ heap and an automatically
 managed JavaScript heap. The application developer needs to be aware of the subtleties
@@ -903,8 +912,8 @@ on \l{Lazy Initialization} for more information.
 
 \section3 Destroy unused objects
 
-If you lazily instantiate components, or dynamically create objects during a JavaScript
-expression, it is often better to manually \c{destroy()} them rather than waiting for
+If you lazy load components, or create objects dynamically during a JavaScript
+expression, it is often better to \c{destroy()} them manually rather than wait for
 automatic garbage collection to do so. See the prior section on
 \l{Controlling Element Lifetime} for more information.
 
@@ -939,7 +948,7 @@ can improve the modularity and maintainability of a component. In those cases, u
 custom properties is encouraged. However, the new type should, if it is used more than
 once, be split into its own component (.qml file) in order to conserve memory.
 
-\section3 Re-use existing components
+\section3 Reuse existing components
 
 If you are considering defining a new component, it's worth double checking that such a
 component doesn't already exist in the component set for your platform. Otherwise, you
@@ -962,40 +971,40 @@ dependent upon decisions made by the application developer.
 The C++ heap will contain:
 \list
   \li the fixed and unavoidable overhead of the QML engine (implementation data
-  structures, context information, and so on)
+  structures, context information, and so on);
   \li per-component compiled data and type information, including per-type property
-  metadata, which is generated by the QML engine depending on which modules are
-  imported by the application and which components the application loads
+  metadata, which is generated by the QML engine depending on which modules and
+  which components are loaded by the application;
   \li per-object C++ data (including property values) plus a per-element metaobject
-  hierarchy, depending on which components the application instantiates
-  \li any data which is allocated specifically by QML imports (libraries)
+  hierarchy, depending on which components the application instantiates;
+  \li any data which is allocated specifically by QML imports (libraries).
 \endlist
 
 The JavaScript heap will contain:
 \list
   \li the fixed and unavoidable overhead of the JavaScript engine itself (including
-  built-in JavaScript types)
+  built-in JavaScript types);
   \li the fixed and unavoidable overhead of our JavaScript integration (constructor
-  functions for loaded types, function templates, and so on)
+  functions for loaded types, function templates, and so on);
   \li per-type layout information and other internal type-data generated by the JavaScript
-  engine at runtime, for each type (see note below, regarding types)
+  engine at runtime, for each type (see note below, regarding types);
   \li per-object JavaScript data ("var" properties, JavaScript functions and signal
-  handlers, and non-optimized binding expressions)
-  \li variables allocated during expression evaluation
+  handlers, and non-optimized binding expressions);
+  \li variables allocated during expression evaluation.
 \endlist
 
 Furthermore, there will be one JavaScript heap allocated for use in the main thread, and
 optionally one other JavaScript heap allocated for use in the WorkerScript thread. If an
 application does not use a WorkerScript element, that overhead will not be incurred. The
 JavaScript heap can be several megabytes in size, and so applications written for
-memory-constrained devices may be best served to avoid using the WorkerScript element
+memory-constrained devices may be best served by avoiding the WorkerScript element
 despite its usefulness in populating list models asynchronously.
 
 Note that both the QML engine and the JavaScript engine will automatically generate their
 own caches of type-data about observed types. Every component loaded by an application
-is a distinct (explicit) type, and every element (component instance) which defines its
+is a distinct (explicit) type, and every element (component instance) that defines its
 own custom properties in QML is an implicit type. Any element (instance of a component)
-which does not define any custom properties is considered by the JavaScript and QML engines
+that does not define any custom property is considered by the JavaScript and QML engines
 to be of the type explicitly defined by the component, rather than its own implicit type.
 
 Consider the following example:
@@ -1037,13 +1046,13 @@ In the previous example, the rectangles \c r0 and \c r1 do not have any custom p
 and thus the JavaScript and QML engines consider them both to be of the same type. That
 is, \c r0 and \c r1 are both considered to be of the explicitly defined \c Rectangle type.
 The rectangles \c r2, \c r3 and \c r4 each have custom properties and are each considered
-to be different (implicit) types. Note that \c r3 and \c r4 are each considered to be of
+to be of different (implicit) types. Note that \c r3 and \c r4 are each considered to be of
 different types, even though they have identical property information, simply because the
 custom property was not declared in the component which they are instances of.
 
 If \c r3 and \c r4 were both instances of a \c RectangleWithString component, and that
 component definition included the declaration of a string property named \c customProperty,
-then \c r3 and \c r4 would be considered to be the same type (that is, they would be
+then \c r3 and \c r4 would be considered to be of the same type (that is, they would be
 instances of the \c RectangleWithString type, rather than defining their own implicit type).
 
 \section2 In-Depth Memory Allocation Considerations
@@ -1065,12 +1074,12 @@ Fragmentation is a C++ development issue. If the application developer is not de
 any C++ types or plugins, they may safely ignore this section.
 
 Over time, an application will allocate large portions of memory, write data to that
-memory, and subsequently free some portions of that memory once it has finished using
+memory, and subsequently free some portions of it once it has finished using
 some of the data. This can result in "free" memory being located in non-contiguous
 chunks, which cannot be returned to the operating system for other applications to use.
 It also has an impact on the caching and access characteristics of the application, as
 the "living" data may be spread across many different pages of physical memory. This
-in turn could force the operating system to swap which can cause filesystem I/O - which
+in turn could force the operating system to swap, which can cause filesystem I/O - which
 is, comparatively speaking, an extremely slow operation.
 
 Fragmentation can be avoided by utilizing pool allocators (and other contiguous memory