/****************************************************************************
**
** Copyright (C) 2015 The Qt Company Ltd.
** Contact: http://www.qt.io/licensing
**
** This file is part of Qt Creator
**
**
** GNU Free Documentation License
**
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of this
** file.
**
**
****************************************************************************/

// **********************************************************************
// NOTE: the sections are not ordered by their logical order to avoid
// reshuffling the file each time the index order changes (i.e., often).
// Run the fixnavi.pl script to adjust the links to the index order.
// **********************************************************************

/*!
    \contentspage {Qt Creator Manual}
    \previouspage creator-analyze-mode.html
    \page creator-qml-performance-monitor.html
    \nextpage creator-valgrind-overview.html

    \title Profiling QML Applications

    You can use the QML Profiler to find causes for typical performance problems
    in your applications, such as slowness and unresponsive, stuttering user
    interfaces. Typical causes include executing too much JavaScript in too few
    frames. All JavaScript must return before the GUI thread can proceed, and
    frames are delayed or dropped if the GUI thread is not ready.

    Another typical cause for similar performance problems is creating,
    painting, or updating invisible items, which takes time in the GUI thread.

    Triggering long-running C++ functions, such as paint methods and signal
    handlers, also takes time in the GUI thread, but is more difficult to see in
    the QML Profiler, because it does not profile C++ code.

    To find excessive use of JavaScript, check the frame rate in animations and
    Scene Graph events, look for gaps, and check whether the application behaves
    as expected. The JavaScript category displays the run time of functions,
    which you should try to keep below 16 ms per frame.

    To find problems caused by handling invisible items, look for dropped
    frames and check that you are not using too many short bindings or signal
    handlers that are updated per frame. You can also \l{Visualizing Overdraw}
    {visualize Scene Graph overdraw} to check scene layout and find items that
    are never visible to the users, because they are located outside the screen
    or hidden beneath other, visible elements.

    If frames get dropped even though JavaScript is not being run, and there are
    large, unexplained gaps in the timeline, check your custom QQuickItem
    implementations. You can use \l{Using Valgrind Code Analysis Tools}
    {Valgrind} or other general purpose profilers to analyze C++ code.

    \section1 Using QML Profiler

    To monitor the performance of an application in the QML Profiler:

    \list 1

        \li To be able to profile an application, you must set up QML debugging
            for the project. For more information, see
            \l{Setting Up QML Debugging}.

        \li In the \uicontrol Projects mode, select a \l{glossary-buildandrun-kit}
            {kit} with Qt version 4.7.4 or later.

            \note To profile applications on devices, you must install Qt 4.7.4
            or later libraries on them.

        \li Select \uicontrol {Analyze > QML Profiler} to profile the current
            application.

        \li Select the
            \inlineimage qtcreator-analyze-start-button.png
            (\uicontrol Start) button to start the application from the
            QML Profiler.

            \note If data collection does not start automatically, select the
            \inlineimage qtcreator-analyzer-button.png
            (\uicontrol {Enable Profiling}) button.

    \endlist

    When you start analyzing an application, the application is launched, and
    the QML Profiler immediately begins to collect data. This is indicated by
    the time running in the \uicontrol Elapsed field.

    Data is collected until you select the \uicontrol {Enable Profiling} button. Data
    collection
    takes time, and therefore, there might be a delay
    before the data is displayed.

    Do not use application commands to exit the application, because data is
    sent to the QML Profiler when you select the \uicontrol {Enable Profiling} button.
    The application continues to run for some seconds, after which it is stopped
    automatically. If you exit the application, the data is not sent.

    Select the \uicontrol {Disable Profiling} button to disable the automatic
    start of the data collection when an
    application is launched. Data collection starts when you select the button
    again.

    To save all the collected data, right-click any QML Profiler view to open
    the context menu, and then select \uicontrol {Save QML Trace}. To view the saved
    data, select \uicontrol {Load QML Trace}. You can also deliver the saved data to
    other developers for examination or load data saved by them.

    \section1 Specifying Flushing Settings

    You can specify flushing settings for the QML Profiler either globally for
    all projects or separately for each project. To specify global settings,
    select \uicontrol Tools > \uicontrol Options > \uicontrol Analyzer.

    To specify custom QML Profiler settings for a particular project, select
    \uicontrol Projects and then select \uicontrol Custom in \uicontrol
    {QML Profiler Settings}. To restore the global settings for the project,
    select \uicontrol {Restore Global}.

    \image qml-profiler-settings.png "QML Profiler Settings"

    Select the \uicontrol {Flush data while profiling} check box to flush the
    data periodically instead of flushing all data when profiling stops. This
    saves memory on the target device and shortens the wait between the
    profiling being stopped and the data being displayed.

    In the \uicontrol {Flush interval} field, set the flush interval in
    milliseconds. The shorter the interval, the more often the data is flushed.
    The longer the interval, the more data has to be buffered in the target
    application, potentially wasting memory. However, the flushing itself takes
    time, which can distort the profiling results.

    \section1 Attaching to Running Qt Quick Applications

    To profile Qt Quick applications that are not launched by \QC, select
    \uicontrol {Analyze > QML Profiler (External)}. You must enable QML debugging and profiling for
    the application in the project build settings. For more information, see
    \l{Setting Up QML Debugging}.

    In the \uicontrol {QML Profiler} dialog, \uicontrol Port field, specify the port to
    listen to.

    \section1 Analyzing Collected Data

    The \uicontrol Timeline view displays graphical representations of QML and
    JavaScript execution and a condensed view of all recorded events.

    \image qtcreator-qml-performance-monitor.png "QML Profiler"

    Each row in the timeline (6) describes a type of QML events that were
    recorded. Move the cursor on an event on a row to see how long it takes and
    where in the source it is being called. To display the information only when
    an event is selected, disable the \uicontrol {View Event Information on Mouseover}
    button (5).

    The outline (10) summarizes the period for which data was collected. Drag
    the zoom range (8) or click the outline to move on the outline. You can
    also move between events by selecting the \uicontrol {Jump to Previous Event} (1)
    and \uicontrol {Jump to Next Event} (2) buttons.

    Select the \uicontrol {Show Zoom Slider} button (3) to open a slider that you can
    use to set the zoom level. You can also drag the zoom handles (9). To reset
    the default zoom level, right-click the timeline to open the context menu,
    and select \uicontrol {Reset Zoom}.

    \section2 Selecting Event Ranges

    You can select an event range (7) to view the frame rate of events and to
    compare it with the frame rate of similar events. Select the
    \uicontrol {Select Range} button (4) to activate the selection tool. Then click in
    the timeline to specify the beginning of the event range. Drag the selection
    handle to define the end of the range. The length of the range indicates the
    frame rate of the event.

    You can use event ranges also to measure delays between two subsequent
    events. Place a range between the end of the first event and the beginning
    of the second event. The \uicontrol Duration field displays the delay between the
    events in milliseconds.

    To zoom into an event range, double-click it.

    To remove an event range, close the \uicontrol Selection dialog.

    \section2 Understanding the Data

    Generally, events in the timeline view indicate how long QML or JavaScript
    execution took. Move the mouse over them to see details. For most events,
    they include location in source code, duration and some relevant parts of
    the source code itself.

    You can click on an event to move the cursor in the code editor to the part
    of the code the event is associated with.

    The following types of events are displayed in the timeline view on one or
    several rows. The availability of event types depends on the version of Qt
    the application was compiled with, the version of Qt Quick it is using, and
    whether \QC or \QCE is used to profile it.

    \table

    \header
        \li Event Category
        \li Description
        \li Minimum Qt Version
        \li Qt Quick Version
        \li Commercial Only

    \row
        \li \uicontrol {Pixmap Cache}
        \li Displays the general amount of pixmap data cached, in pixels. In
            addition, displays a separate event for each picture being loaded,
            with specifics about its file name and size.
        \li Qt 5.1
        \li Qt Quick 2
        \li \image ok

    \row
        \li \uicontrol {Scene Graph}
        \li Displays the time when scene graph frames are rendered and some
            additional timing information for the various stages executed to do
            so.
        \li Qt 5.1
        \li Qt Quick 2
        \li \image ok
    \row
        \li \uicontrol {Memory Usage}
        \li Displays block allocations of the JavaScript memory manager.
            Generally, the memory manager will reserve larger blocks of memory
            in one piece and later hand them out to the application in smaller
            bits. If the application requests single blocks of memory
            surpassing a certain size, the memory manager will allocate those
            separately. Those two modes of operation are shown as events of
            different colors.
            The second row displays the actual usage of the allocated memory.
            This is the amount of JavaScript heap the application has actually
            requested.
        \li Qt 5.4
        \li Qt Quick 2
        \li \image ok

    \row
        \li \uicontrol {Input Events}
        \li Displays mouse and keyboard events.
        \li Qt 4.7.4
        \li Qt Quick 1 or Qt Quick 2
        \li \image ok

    \row
        \li \uicontrol Painting
        \li Displays the time spent painting the scene for each frame.
        \li Qt 4.7.4
        \li Qt Quick 1
        \li

    \row
        \li \uicontrol Animations
        \li Displays the amount of animations that are active and the frame
            rate that they are running at.
            Information about render thread animations is displayed for
            applications that are built with Qt 5.3 or later. Render thread
            animations are shown in a separate row then.
        \li Qt 5.0 (Qt 5.3)
        \li Qt Quick 2
        \li

    \row
        \li \uicontrol Compiling
        \li Displays the time spent compiling the QML files.
        \li Qt 4.7.4
        \li Qt Quick 1 or Qt Quick 2
        \li

    \row
        \li \uicontrol Creating
        \li Displays the time spent creating the elements in the scene. In Qt
            Quick 2, creation of elements takes place in two stages. The first
            stage is for the creation of the data structures, including child
            elements. The second stage represents the completion callbacks. Not
            all elements trigger completion callbacks, though. The stages are
            shown as separate events in the timeline.
            For Qt Quick 2 applications compiled with versions of Qt before
            5.2.1 only the creation of top-level elements is shown, as single
            events.
        \li Qt 4.7.4 (Qt 5.2.1)
        \li Qt Quick 1 or Qt Quick 2
        \li

    \row
        \li \uicontrol Binding
        \li Displays the time when a binding is evaluated and how long the
            evaluation takes.
        \li Qt 4.7.4
        \li Qt Quick 1 or Qt Quick 2
        \li

    \row
        \li \uicontrol {Handling Signal}
        \li Displays the time when a signal is handled and how long the
            handling takes.
        \li Qt 4.7.4
        \li Qt Quick 1 or Qt Quick 2
        \li

    \row
        \li \uicontrol JavaScript
        \li Displays the time spent executing the actual JavaScript behind
            bindings and signal handlers. It lists all the JavaScript functions
            you may be using to evaluate bindings or handle signals.
        \li Qt 5.3
        \li Qt Quick 2
        \li

    \endtable

    \section2 Analyzing Scene Graph Events

    In order to understand the scene graph category, it's important to
    understand how the Qt Quick scene graph works. See
    \l {Qt Quick Scene Graph} and \l {Qt Quick Scene Graph Renderer} for a
    detailed description. The following events are reported in the
    \uicontrol {Scene Graph} category. Not all events are generated by all render
    loops. In the Windows and Basic render loops everything runs in the same
    thread and the distinction between GUI thread and render thread is
    meaningless.

    If you set the environment variable QSG_RENDER_TIMING, you get a textual
    output of similar, but slightly different timings from the application
    being profiled. For easier orientation, the differences are listed below.

    \table
    \header
        \li Event Type
        \li Thread
        \li Render Loop Types
        \li Label in output of QSG_RENDER_TIMING
        \li Description
        \li Caveats
    \row
        \li \uicontrol {Polish}
        \li GUI
        \li Threaded, Basic, Windows
        \li polish
        \li Final touch-up of items before they are rendered using
            QQuickItem::updatePolish().
        \li Versions of Qt prior to Qt 5.4 record no polish times for the basic
            render loop and incorrect ones for the windows render loop.
    \row
        \li \uicontrol {GUI Thread Wait}
        \li GUI
        \li Threaded
        \li lock
        \li Executing slots connected to the QQuickWindow::afterAnimating()
            signal and then locking the render thread's mutex before waiting on
            the same mutex at \uicontrol {GUI Thread Sync}. If this starts long
            before \uicontrol {Render Thread Sync}, there is \e free  time in the GUI
            thread you could be using for running additional QML or JavaScript.
        \li None
    \row
        \li \uicontrol {GUI Thread Sync}
        \li GUI
        \li Threaded
        \li blockedForSync
        \li The time the GUI thread is blocked, waiting for the render thread
            to synchronize the QML state into the scene graph.
        \li None
    \row
        \li \uicontrol {Animations}
        \li GUI
        \li Threaded, Windows
        \li animations
        \li Advancing animations in the GUI thread. The basic render loop does
            not drive animations in sync with the rendering. This is why no
            animation events will be shown when using the basic render loop.
            Watch the \uicontrol {Animations} category to see animation timing in
            this case.
        \li None
    \row
        \li \uicontrol {Render Thread Sync}
        \li Render
        \li Threaded, Basic, Windows
        \li Frame rendered ... sync
        \li Synchronizing the QML state into the scene graph using
            QQuickItem::updatePaintNode().
        \li None
    \row
        \li \uicontrol {Render}
        \li Render
        \li Threaded, Basic, Windows
        \li Frame rendered ... render
        \li Total time spent rendering the frame, including preparing and
            uploading all the necessary data to the GPU. This is the \e gross
            render time. Do not confuse it with the \e net \uicontrol{Render Render}
            time below.
        \li With versions of Qt prior to Qt 5.5, the gross render time and the
            below breakup of render times may be misaligned by some
            microseconds due to different, unsynchronized timers being used to
            measure them. For example \uicontrol {Render Preprocess} might seem to
            start before \uicontrol {Render Thread Sync} is finished.
    \row
        \li \uicontrol {Swap}
        \li Render
        \li Threaded, Basic, Windows
        \li Frame rendered ... swap
        \li Swapping frames after rendering.
        \li The output of swap times triggered by setting QSG_RENDER_TIMING is
            incorrect for the basic render loop and versions of Qt prior to
            Qt 5.4. The QML profiler shows the correct swap times.
    \row
        \li \uicontrol {Render Preprocess}
        \li Render
        \li Threaded, Basic, Windows
        \li time in renderer ... preprocess
        \li Calling QSGNode::preprocess() on all nodes that need to be
            preprocessed. This is part of the gross \uicontrol {Render} step.
        \li May not be properly aligned with \uicontrol {Render} with versions of Qt
            prior to Qt 5.5.
    \row
        \li \uicontrol {Render Update}
        \li Render
        \li Threaded, Basic, Windows
        \li time in renderer ... updates
        \li Iterating and processing all the nodes in the scene graph to update
            their geometry, transformations, opacity, and other state. In the
            \uicontrol {Render Thread Sync} stage, each node is updated separately
            with state from the GUI thread. In \uicontrol {Render Update}, all the
            nodes are combined to create the final scene. This is part of the
            gross \uicontrol {Render} step.
        \li May not be properly aligned with \uicontrol {Render} with versions of Qt
            prior to Qt 5.5.
    \row
        \li \uicontrol {Render Bind}
        \li Render
        \li Threaded, Basic, Windows
        \li time in renderer ... binding
        \li Binding the correct framebuffer for OpenGL rendering. This is part
            of the gross \uicontrol {Render} step.
        \li May not be properly aligned with \uicontrol {Render} with versions of Qt
            prior to Qt 5.5.
    \row
        \li \uicontrol {Render Render}
        \li Render
        \li Threaded, Basic, Windows
        \li time in renderer ... rendering
        \li The actual process of sending all the data to the GPU via OpenGL.
            This is part of the gross \uicontrol {Render} step.
        \li May not be properly aligned with \uicontrol {Render} with versions of Qt
            prior to Qt 5.5.
    \row
        \li \uicontrol {Material Compile}
        \li Render
        \li Threaded, Basic, Windows
        \li shader compiled
        \li Compiling GLSL shader programs.
        \li None
    \row
        \li \uicontrol {Glyph Render}
        \li Render
        \li Threaded, Basic, Windows
        \li glyphs ... rendering
        \li Rendering of font glyphs into textures.
        \li Versions of Qt prior to Qt 5.4 report incorrect times for these
            events.
    \row
        \li \uicontrol {Glyph Upload}
        \li Render
        \li Threaded, Basic, Windows
        \li glyphs ... upload
        \li Uploading of glyph textures to the GPU.
        \li Versions of Qt prior to Qt 5.4 report incorrect times for these
            events.
    \row
        \li \uicontrol {Texture Bind}
        \li Render
        \li Threaded, Basic, Windows
        \li plain texture ... bind
        \li Binding a texture in the OpenGL context using glBindTextures.
        \li None
    \row
        \li \uicontrol {Texture Convert}
        \li Render
        \li Threaded, Basic, Windows
        \li plain texture ... convert
        \li Converting the format and downscaling an image to make it suitable
            for usage as a texture.
        \li None
    \row
        \li \uicontrol {Texture Swizzle}
        \li Render
        \li Threaded, Basic, Windows
        \li plain texture ... swizzle
        \li Swizzling the texture data on the CPU if necessary.
        \li None
    \row
        \li \uicontrol {Texture Upload}
        \li Render
        \li Threaded, Basic, Windows
        \li plain texture ... upload / atlastexture uploaded
        \li Uploading the texture data to the GPU.
        \li None
    \row
        \li \uicontrol {Texture Mipmap}
        \li Render
        \li Threaded, Basic, Windows
        \li plain texture ... mipmap
        \li Mipmapping a texture on the GPU.
        \li None
    \row
        \li \uicontrol {Texture Delete}
        \li Render
        \li Threaded, Basic, Windows
        \li plain texture deleted
        \li Deleting a texture from the GPU that became unnecessary.
        \li None
    \endtable

    \section1 Viewing Events

    The \uicontrol Events view displays the number of times each binding, create,
    compile, JavaScript, or signal event is triggered and the average time it
    takes. This allows you to examine which events you need to optimize. A high
    number of occurrences might indicate that an event is triggered
    unnecessarily. To view the median, longest, and shortest time for the
    occurrences, select \uicontrol {Extended Event Statistics} in the context menu.

    Click on an event to move to it in the source code
    in the code editor.

    \image qtcreator-analyzer-bindings.png "Events view"

    The \uicontrol Callers and \uicontrol Callees panes show dependencies between events.
    They allow you to examine the internal functions of the application.
    The \uicontrol Callers pane summarizes the QML events that trigger a binding.
    This tells you what caused a change in a binding.
    The \uicontrol Callees pane summarizes the QML events that a binding triggers.
    This tells you which QML events are affected if you change a binding.

    Click on an event to move to it in the source code in the code editor.

    When you select an event in the \uicontrol Timeline view, information about it is
    displayed in the \uicontrol Events view. To view an event range in the \uicontrol Events
    view, select \uicontrol {Limit Events Pane to Current Range} in the context menu
    in the \uicontrol Timeline view.

    To copy the contents of one view or row to the clipboard, select
    \uicontrol {Copy Table} or \uicontrol {Copy Row} in the context menu.

    JavaScript events are shown in the \uicontrol Events view only for applications
    that use Qt Quick 2 and are compiled with Qt 5.3 or later.
*/
