aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/items.pri
Commit message (Collapse)AuthorAgeFilesLines
* Flickable: Use increased default flick parameters on BB10Oleg Shparber2013-12-111-0/+1
| | | | | | | | | | | | | | | Due to the high resolution the display default flicking speed is rather slow. This change introduces increased values of QML_FLICK_DEFAULTMAXVELOCITY and QML_FLICK_DEFAULTDECELERATION which feel closer to the native experience. Also cleans up the flick variables a little by moving them to their own header, so that QQuickPathView can also benefit from the improved behavior on BB10. Change-Id: I80878d4cc2a53a8f530b1dc8674f729f70a83119 Reviewed-by: Alan Alpert <aalpert@blackberry.com> Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
* Adapt Qt Quick 2 renderer to work with OpenGL Core ProfileSean Harmer2013-11-131-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The basic approach is to have the batched renderer create and bind a vertex array object if it detects we are using an OpenGL Core profile context. The VAO is bound for the duration of the QQ2 renderer's work cycle and unbound at the end so as to not interfere with any other VAO's a user may wish to use. All shaders have been copied and ported to be compliant with the GLSL 150 core specification which is the minimum for a Core profile context (OpenGL 3.2 Core). We are not using any newer features as yet so this will work anywhere we can get a Core profile context. The QSGShaderSourceBuilder class has been extended to resolve any requests for shaders to the same basefilename with "_core" appended prior to any file extension. This could be extended in the future to allow version, or GPU or platform specific shaders. The QSGShaderSourceBuilder has also been extended to allow it to insert #define definitions in the prologue of a shader. Any such definition is inserted: * After the last #extension directive (if any are found) * Otherwise after the #version directive (if found) * Otherwise at the start of the shader source This is required by the custom particle shaders which make extensive use of such #defines. In addition the mechanism used by the distance field glyph cache to extend the cache with new glyphs has been modified to work (and work more efficiently) when using a Core profile context. Rather than using a shader program and a buffer filling quad to blit the old texture into the new cache texture, we instead use the technique of framebuffer blitting. The existing fallback implementation using glTexSubImage2D() is still available if needed. The DECLARATIVE_EXAMPLE_MAIN macro has been extended to allow easy testing of any of the QtDeclarative examples with a core profile context. Just run the example with QT_QUICK_CORE_PROFILE=1 ./text for e.g. The only ones that may not work out of the box are those that provide GLSL shader source e.g. the customparticles or shader effect examples. These work fine if the shader source is adapted to GLSL 150 core. In the future it may be a good idea to expose some context property to QML that the user can use to determine what shader source variation to provide to Qt Quick. Along these lines it would also be very nice to allow the provision of shader source to ShaderEffect or CustomParticle from a separate source file just as we now do within Qt Quick. Task-number: QTBUG-32050 Change-Id: Ia6e9f06dbb8508af9ae03c6b60fb418b4cc9e41f Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Refactor shaders into seprate GLSL source filesSean Harmer2013-10-311-1/+10
| | | | | | | | | | | | | | | | | | | | | | The default implementation of QSGShaderMaterial::vertexShader() and fragmentShader() now loads the GLSL source from a list of source files that can be specified via the setShaderSourceFile() or setShaderSourceFiles() functions. Multiple shader source files for each shader stage are supported. Each source file will be read in the order specified and concatenated together before being compiled. The other places where Qt Quick 2 loads shader source code have been adapted to use the new QSGShaderSourceBuilder, which is also used internally by QSGMaterial. This puts Qt Quick 2 into a better state ready to support OpenGL core profile and to load different shaders based upon OpenGL version, profile, GPU vendor, platform, etc. Change-Id: I1a66213c2ce788413168eb48c7bc5317e61988a2 Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
* Convenience class for FBO rendering in Qt QuickGunnar Sletta2013-09-251-2/+4
| | | | | Change-Id: I5712bbfa0cde9f2fe5fddc35c4cc23597717065c Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Optimize QQuickTextEdit for larger documents.Pierre Rossi2013-03-201-0/+2
| | | | | | | | | | | | | | | | | The rationale is to not end up re-processing the whole document on each update Since we know where the editing takes place, we can break down the text edit's contents in several text nodes and only re-create the affected text nodes upon editing. This requires ripping out the SelectionEngine helper class from QQuickTextNode so that QQuickTextEdit can tap into its functionality directly. A positive side-effect of this exercise is that it should be much harder to to come across GlyphNodes packing more than 16300 glyphs or so. Task-number: QTBUG-29596 Change-Id: Id29b0709baa43f5b29c44ab02398ba996be3e28a Reviewed-by: Yoann Lopes <yoann.lopes@digia.com>
* Add QQuickTextDocumentFrederik Gladhorn2013-02-191-0/+2
| | | | | | | | | | | | | Adding QQuickTextDocument as a way to access the QTextDocument of QQuickTextEdit from C++. This makes it possible to use a QSyntaxHighlighter from C++ without exposing more than one single qml property in the TextEdit. Change-Id: If1790b591493adcb0b68aef0c8ca706e00450657 Reviewed-by: Alan Alpert <aalpert@rim.com> Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
* Move the model classes from QtQuick to QtQmlAlan Alpert2013-01-241-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | This is needed for proper support of non-GUI instantiators in QtQml. Only private C++ classes are affected. Aside from name changes, model classes now operate on QObjects instead of QQuickItems, leading to minor changes in the implementation of QtQuick classes using them. The old QML type names will still be registered in the QtQuick import for the forseeable future, but pointing to the new classes. The new QML types will be added in a second commit. Classes Affected: QQuickVisualDataGroup -> QQmlDataGroup QQuickVisualDataModel -> QQmlDelegateModel QQuickVisualItemModel -> QQmlObjectModel QQuickVisualModel -> QQmlInstanceModel QQuickChangeSet -> QQmlChangeSet QQuickListAccessor -> QQmlListAccessor QQuickListCompositor -> QQmlListCompositor QQuickPackage -> QQuickPackage (just moved for now) Change-Id: Ia19e630e53bfa9e5d459e289596cd11df1ea3930 Reviewed-by: Andrew den Exter <andrew.den.exter@qinetic.com.au>
* Complete rewrite of threaded render loop.Gunnar Sletta2013-01-181-6/+2
| | | | | | | | | | | | | | | | This change starts using the superior implementation of the scene graph render loop which has been worked on in the scenegraph-playground project for a while. It uses a far more straightforward locking/sync paradigm compared to the existing one and is less deadlock and error prone. It also enables the scene graph thread to run on its own when the GUI thread is blocked, enabling threaded animations. This changes also introduces a naming change inside Qt Quick from "Window Manager" -> "Render Loop" as that fits better to what the code does. Change-Id: I1c2170ee04fcbef79660bd7dae6cace647cdb276 Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
* Remove interim compatibility measuresAlan Alpert2012-10-161-1/+0
| | | | | | | | Also update some variables in qtdeclarative which failed to update rootItem->contentItem. Change-Id: Id34e29546a22a74a7ae2ad90ee3a8def6fc541d3 Reviewed-by: Alan Alpert <416365416c@gmail.com>
* QQuickRenderThreadSingleContextWindowManager in separate filesAlan Alpert2012-07-241-2/+4
| | | | | Change-Id: I90364c3e96e5bcbff84d8da574af5695a0fd7993 Reviewed-by: Glenn Watson <glenn.watson@nokia.com>
* QQuickCanvas renamesAlan Alpert2012-07-171-2/+3
| | | | | | | | | | | | | | | | QQuickCanvas is now called QQuickWindow QQuickCanvas::rootItem is now QQuickWindow::contentItem QQuickItem::canvas is now QQuickItem::window QQuickItem::ItemChangeData::canvas is also renamed window QQuickCanvas::grabFrameBuffer is now QQuickWindow::grabWindow The functions related to the color property have dropped the clear from their names. The first three changes have interim compatibility measures in place to ease the transition. Change-Id: Id34e29546a22a74a7ae2ad90ee3a8def6fc541d2 Reviewed-by: Martin Jones <martin.jones@nokia.com>
* Change antialiasing method for QML2.Kim Motoyoshi Kalland2012-07-131-2/+0
| | | | | | | | | | | | | Since multisampling can require a lot of memory, and might not be supported on some hardware, turn off multisampling and implement antialiasing in the vertex shader instead. The alternative method of antialiasing is implemented for Rectangle, Image, BorderImage and AnimatedImage, and must be explicitly enabled by setting the new antialiasing property. Task-number: QTBUG-26268 Change-Id: I39a93d978658a494bf51e9f0fd02d8414eb8be12 Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
* Defer construction of TextEdit/TextInput delegates.Andrew den Exter2012-05-141-0/+2
| | | | | | | | | | | | | | | Don't create instances of the delegate components until the item gains focus, or the cursorVisible property is set to true. Cursor delegates are typically small and relatively fast to create and so won't have a significant cost during a one off focus in event, but that cost can still add up when creating a number of TextInputs or TextEdits at once. If a delegate that is instantiated immeditately is required it is possible to instead create a child item and bind to the cursorRectangle and cursorVisible properties. Change-Id: I5ec2b5b6a30e534aee3dd5a58c6a5ac0686f5ce2 Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
* Merge master <-> api_changesMatthew Vogt2012-03-051-2/+6
|\ | | | | | | Change-Id: Iad2f07b989b25349fd2d4fff010e24dcd5a1688f
| * Separate view transition functionality into new fileBea Lam2012-02-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move most of the view transition functionality from qquickitemview* into qquickitemviewtransition*. - Move QQuickViewTransitionAttached - Move QQuickItemViewTransitionManager, rename to QQuickItemViewTransitionJob - Move FxViewItem transition-specific features into new QQuickViewItem - Move transition-specific functions like transitionNextReposition() and canTransition() into QQuickItemViewTransitioner which holds all the transition objects now Also mention in docs that there's no defined order for choosing between multiple matching displaced transitions. Change-Id: I8701c0d40d2af152c5d432a4c8de646854c76ea2 Reviewed-by: Martin Jones <martin.jones@nokia.com>
| * Rename SpriteImage to SpriteSequenceAlan Alpert2012-02-281-2/+2
| | | | | | | | | | | | | | Also rename Sprite::frames->Sprite::frameCount Change-Id: I2e7a71adc37044fd696ffda2a5da4835725ba3a8 Reviewed-by: Alan Alpert <alan.alpert@nokia.com>
| * Add AnimatedSpriteAlan Alpert2012-02-281-0/+2
| | | | | | | | | | | | | | | | A simpler sprite image element for the simple usecase. Because sometimes an engine with stochastic capabilities is overkill. Change-Id: I2b76c5d417719e92a548f6266bffd563dc016983 Reviewed-by: Alan Alpert <alan.alpert@nokia.com>
* | Rename QDeclarative symbols to QQuick and QQmlMatthew Vogt2012-02-241-3/+3
|/ | | | | | | | | | | | | Symbols beginning with QDeclarative are already exported by the quick1 module. Users can apply the bin/rename-qtdeclarative-symbols.sh script to modify client code using the previous names of the renamed symbols. Task-number: QTBUG-23737 Change-Id: Ifaa482663767634931e8711a8e9bf6e404859e66 Reviewed-by: Martin Jones <martin.jones@nokia.com>
* Add accessibility to qmlFrederik Gladhorn2012-01-021-1/+3
| | | | | | | | | | | | | | | This consists of two parts: An attached property for QML items and a plugin for the accessibility framework. The attached property simply takes care of some properties (name, role) that are needed in order to expose semantics of the application to assistive tools. The plugin exposes the hierarchy of QML items to the accessibility framework. Change-Id: I32f5603d0d9549b01b3645b205b710b9801762f7 Reviewed-by: Jan-Arve Sæther <jan-arve.saether@nokia.com>
* Minimize the number of objects created per item in VisualDataModel.Andrew den Exter2011-12-231-0/+1
| | | | | | | | | | | | | | Derive from QDeclarativeContext and reference count the context object instead of parenting it to the context. Combined with a weak persistent v8 handle the allows the context object to be returned by javascript accessors instead of creating a new instance for every use. In addition to the efficiency advantages of creating fewer objects, routing all data access through a single object means that object can also persist data instead of just acting as a proxy. Change-Id: I107dc8c901f16f2a4b420ff1cbffa7a6be27de89 Reviewed-by: Martin Jones <martin.jones@nokia.com>
* Merge QQuickLineControl into QQuickTextInput.Andrew den Exter2011-12-161-2/+0
| | | | | | | | | | There's no clear separation of responsibilty between these classes and keeping them in sync and forwarding signals is a unnecessary overhead that can be avoided by combining them. Task-number: QTBUG-22627 Change-Id: I4350eb3c612b10d4ed34886374889ae893b8183a Reviewed-by: Martin Jones <martin.jones@nokia.com>
* Create a copy of QLineControl in the QtDeclarative library.Andrew den Exter2011-12-121-0/+2
| | | | | | | | | | First half of a move of QLineControl from qtbase to qtdeclarative, some time in the future QLineControl will be deleted from qtbase to finish the move. Task-number: QTBUG-22627 Change-Id: I0c3449f57f1a3296a0ff52f2b9a1a78041ae28b2 Reviewed-by: Joona Petrell <joona.t.petrell@nokia.com>
* Create a copy of QTextControl in the QtDeclarative library.Andrew den Exter2011-12-091-0/+3
| | | | | | | | | | | First half of a move of QTextControl from qtbase to qtdeclarative, some time in the future QTextControl will be deleted from qtbase to finish the move. Task-number: QTBUG-22627 Change-Id: I72da2c71ab5b090e2a0a15219b81e522e97c541b Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
* Add Screen attached objectAlan Alpert2011-12-091-0/+2
| | | | | | | | | | | Use this to get details of the screen such as size and current orientation. As well as adding its own example, this commit updates Calculator to use Screen instead of Runtime for orientation. Change-Id: I1b73d2ee22a92b1dee827de1bd893eebec9f5817 Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
* Implemented multiple windows and GL context sharingGunnar Sletta2011-12-081-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | What was traditionally the QQuickRenderLoop which was used to support one QQuickCanvas instance has now grown to support multiple QQuickCanvas instances and is now called QQuickWindowManager, of which there are two implementations. QQuickRenderThreadSingleContextWindowManager: One QSGContext and one OpenGL context is being used to draw all the windows and we alternate between which surface the gl context is bound to. This implementation relies on that swap does not block, but that the graphics pipeline is vsynced and will eventually block as the buffer queue is filled up. This is the behavior we get on Mac OS X and Wayland. The benefit of this implementation is that we have vsync'ed animations, and the synchronizaiton between GUI and render thread is simple. (well, simple relative to the alternative, that is). QQuickTrivialWindowManager: One QSGContext and one OpenGL context is being used on the GUI thread. Animations are ticked from a timer. Performance of this implementation will deteriorate if the driver is using blocking swap. Task-number: QTBUG-19455 Change-Id: Ib961ac7d71eb49c70a057872b7cac020c4d19f3d Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
* Say hello to QtQuick moduleKent Hansen2011-12-021-0/+131
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: Lars Knoll <lars.knoll@nokia.com> Change-Id: Ia52be9373172ba2f37e7623231ecb060316c96a7 Reviewed-by: Kent Hansen <kent.hansen@nokia.com> Reviewed-by: Sergio Ahumada <sergio.ahumada@nokia.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-01 22:15:34 +0000