| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two ways of setting this right now. One is to set it on
startup using an environment varible.
QSG_VISUALIZE=
"batches" - Visualize batchtes in the renderer. Merged batches are
drawn with solid color and Unmerged batches are drawn with a diagonal
line pattern. Few unique colors means good batching. Unmerged batches
are bad if they contain many individual nodes.
"clip" - Visualize clipping as red areas on top of the scene.
"overdraw" - Visualize all items in 3D to highlight overdraws. This mode
can also be used to detect geometry outside the viewport to some
extent. Opaque items are rendered with a green tint while translucent
items are rendered with a red tint. The bounding box for the viewport
is rendered in blue. Opaque content is easier for the scenegraph to
process and it can also be faster to render on some hardware.
"changes" - Changes in the scenegraph are visualized with a flashing
overlay with a random color. Changes on a primitive is visualized with
a solid color while changes in an ancestor, such as a matrix or
opacity changes is visualized with a pattern.
The second way to set the visualization mode is to set it at runtime
through QString QQuickWindowPrivate::customRenderMode. This "API" is
string based so it is not tied to the batch renderer and in theory can
support other custom renderers.
The visualized elements do not respect clipping and rendering order
is arbitrary.
Change-Id: I31efbe53fc905145bf48080ede3e36945cb60dcf
Reviewed-by: Michael Brasser <michael.brasser@live.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
