1. Aug 25, 2014
  2. May 01, 2014
  3. Apr 07, 2014
  4. Oct 21, 2013
    • Gunnar Sletta's avatar
      Prevent badly formed texture nodes in the scene graph. · 486d367e
      Gunnar Sletta authored
      
      A texture based node without a valid texture is not allowed,
      as the material and the renderer will only tolerate
      well-formed nodes. If a node is missing any part of its material
      state it should not be in the scene graph in the first place.
      
      Because of an "optimization" in QSGDefaultImageNode::setTexture
      and QSGSimpleTextureNode::setTexture, we must temporarily set
      the texture to 0 to ensure that it gets updated properly. This
      temporarily puts the node into an invalid state which can lead
      to crashes when QSGNode::markDirty() reaches the renderer.
      
      Task-number: QTBUG-34062
      Change-Id: Ic1735c9b974b90b3684262de9589133c961bac6e
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@digia.com>
      486d367e
  5. Sep 30, 2013
  6. Aug 12, 2013
  7. Apr 16, 2013
    • Sean Harmer's avatar
      Add a way of transforming texture coordinates of a simple textured quad · 5c722557
      Sean Harmer authored
      
      This commit introduces the enum TextureCoordinatesTransformFlag and
      corresponding QFlags OR combination TextureCoordinatesTransformMode.
      This enum is used to control the orientation of texture coordinates
      relative to window/item coordinates.
      
      The common use case addressed by this commit is when rendering to a
      texture via an FBO using some 3rd party OpenGL library. Some libraries
      do not offer a way to orient the rendered output which results in the
      texture being displayed upside down when used in conjunction with
      QSGSimpleTextureNode.
      
      There are a number of possible solutions to this:
      
      1 Mirror the item by scaling by -1 in the y-direction in QML document
      
      2 Use a custom material (shader) that transforms texture coordinates
        in GLSL
      
      3 Generate texture coordinates differently
      
      This commit opts for approach 3. Approach 1 is ugly and visible to the
      end user and also causes more work when other transformations interact
      with the necessary scaling. Approach 2 has a performance cost in both
      switching material (shader) and also in additional per-vertex or per-
      fragment operations. The chosen approach hides it from the end user
      and has zero runtime cost delta compared to any other textured quad.
      
      Change-Id: I95870da50a09d113aeff2681bfd458669ec7a5a4
      Reviewed-by: default avatarGunnar Sletta <gunnar.sletta@digia.com>
      5c722557
  8. Jan 10, 2013
  9. Sep 23, 2012
  10. Sep 07, 2012
  11. Feb 24, 2012
  12. Jan 30, 2012
  13. Jan 23, 2012
  14. Jan 17, 2012
  15. Dec 02, 2011
    • Kent Hansen's avatar
      Say hello to QtQuick module · 6c8378ea
      Kent Hansen authored
      
      This change moves the QtQuick 2 types and C++ API (including
      SceneGraph) to a new module (AKA library), QtQuick.
      
      99% of this change is moving files from src/declarative to
      src/quick, and from tests/auto/declarative to
      tests/auto/qtquick2.
      
      The loading of QtQuick 2 ("import QtQuick 2.0") is now delegated to
      a plugin, src/imports/qtquick2, just like it's done for QtQuick 1.
      
      All tools, examples, and tests that use QtQuick C++ API have gotten
      "QT += quick" or "QT += quick-private" added to their .pro file.
      
      A few additional internal QtDeclarative classes had to be exported
      (via Q_DECLARATIVE_PRIVATE_EXPORT) since they're needed by the
      QtQuick 2 implementation.
      
      The old header locations (e.g. QtDeclarative/qquickitem.h) will
      still be supported for some time, but will produce compile-time
      warnings. (To avoid the QtQuick implementation using the
      compatibility headers (since QtDeclarative's includepath comes
      first), a few include statements were modified, e.g. from
      "#include <qsgnode.h>" to "#include <QtQuick/qsgnode.h>".)
      
      There's a change in qtbase that automatically adds QtQuick to the
      module list if QtDeclarative is used. Together with the compatibility
      headers, this should help reduce the migration pain for existing
      projects.
      
      In theory, simply getting an existing QtDeclarative-based project
      to compile and link shouldn't require any changes for now -- but
      porting to the new scheme is of course recommended, and will
      eventually become mandatory.
      
      Task-number: QTBUG-22889
      Reviewed-by: default avatarLars Knoll <lars.knoll@nokia.com>
      Change-Id: Ia52be9373172ba2f37e7623231ecb060316c96a7
      Reviewed-by: default avatarKent Hansen <kent.hansen@nokia.com>
      Reviewed-by: default avatarSergio Ahumada <sergio.ahumada@nokia.com>
      6c8378ea
  16. Sep 27, 2011
  17. Jul 08, 2011
  18. May 20, 2011
  19. May 06, 2011
  20. Apr 27, 2011