/****************************************************************************
**
** Copyright (C) 2015 The Qt Company Ltd.
** Contact: http://www.qt.io/licensing/
**
** This file is part of Qt Quick 2d Renderer module of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see http://www.qt.io/terms-conditions. For further
** information use the contact form at http://www.qt.io/contact-us.
** $QT_END_LICENSE$
**
****************************************************************************/

/*!
    \contentspage{index.html}{Qt Quick 2D Renderer}
    \page qtquick2drenderer-performance.html
    \previouspage qtquick2drenderer-limitations.html

    \title Performance Guide

    Since \RENDERER does not use OpenGL, we lose the ability to use many
    optimizations that can improve rendering speed. To get the most out of
    \RENDERER there are some guidelines that should be followed.

    \section1 2D Hardware Acceleration

    \RENDERER is designed to use operations that can be accelerated by 2D
    acceleration hardware.  2D hardware acceleration uses platform plugins that take advantage of
    the QBlitter API (like DirectFB).

    \section1 Animation

    It is important to keep in mind that with Qt Quick 2 the entire window will
    need to be rendered every time a node in the scene graph is marked dirty.
    There is no partial update mechanimism that will update only the dirty regions
    of the window. This means that any animation that is running will be forcing
    a full repaint of the window, and with \RENDERER this can cause a heavy CPU load.

    \section1 Transforms

    Transformations come with no performance penalty when rendering the scene
    graph with the OpenGL renderer. This is not the case with \RENDERER.
    Translation operations do not come with performance penalties, but scaling
    and rotation transformations should be avoided whenever possible.

    \section1 Hidden Items

    \RENDERER will paint all items that are not hidden explicitly with either
    the visibility property or with an opacity of 0. Without OpenGL there is no
    depth buffer to check for items completely obscured by opaque items, so
    everything will be painted - even if it is unnecessary.

    \section1 Pixel Fill Budget

    When developing an application that will be using \RENDERER, it is important
    to keep in mind your pixel fill budget, or the the amount of pixels you
    can push to the screen in the time needed for your target framerate.  For
    example, if your goal is to render your application at 60 frames per second,
    then you have about 16 milliseconds render to the framebuffer before
    needing to flush the pixels to the screen.  Depending on your hardware's
    performance, you will only be able to handle a finite amount of pixel write
    operations before the 16 milliseconds expire.  The interface you design
    should take into consideration that each added item subtracts from
    your pixel fill budget.

    \RENDERER uses the painters algorithm to paint each item in the scene
    back-to-front.  If you have an interface that stacks many items on top of
    each other, keep in mind that each layer is painted completely, not just the
    parts that are visible.  It can be very easy to waste your pixel fill
    budget with too many over-paints.

*/