| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Commit 7d983077 removed the getter for the renderableNodes that was
added with commit ce831a4b, as it "appears unused". It is though used by
GammaRay. This commit readds the API, this time including a short
comment about the usage by GammaRay.
Change-Id: I06d107a959c587f49389ac356a60ab7ffd79d00d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |\
| |
| |
| | |
Change-Id: I71b1212085da85f03f4ff0e3ee5cb56a401998ae
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We need to repaint everything on devicePixelRatio change,
like we do on size change.
Task-number: QTBUG-66810
Change-Id: I6b2c2ae92335a0aca731a4b0e7621cf7d08881e3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In both cases, the container holds pointers, so stability of
references can be ruled out as a cause for using linked lists. Both
containers are also only ever appended to and then consumed, so there
are no insertions in the middle that a linked list may speed up. Last,
it also cannot be the sheer size of the container, as QLinkedList has
3x the memory consumption of a vector.
We conclude that none of the things that make QLinkedList a container
of choice apply here, so we can use a QVector instead.
In QSGAbstractSoftwareRenderer, there was an accessor for the linked
list member, but it appears unused, so was removed.
Change-Id: I273f89c0d1267444019088371a5eb0b3b32a763c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
| |
|
|
|
|
|
|
| |
+ add some (private) API to make some more data about the rendering
available to GammaRay.
Change-Id: I059f09e663fa9541ec2b0f002b1a0253dd5ea7df
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
|
| |
This generates more compact code, saving 20480 bytes on disk
(Linux 64 bit, release build).
Change-Id: I73d6d88b7b61b87a5d714e131fcf86ee80c83f38
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The pixmap renderer sets up QPainter's window coordinates system but still
positions the background node in device coordinates. If the window rectangle is
QRect(x, y, w, h) then the background rectangle will be set to QRect(0, 0, w,
h). As the rendering output is clipped to the background rectangle, this means
that the image will be left with transparent bands of x pixels on the right and
y pixels on the bottom.
Task-number: QTBUG-62867
Change-Id: I3b2c18dafda4381b0daa64f849330f51bcc743b2
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
If the content of a layer completely covers every pixel of
it, mark that layer as opaque so that we can avoid alpha
blending where possible.
Change-Id: Ia0be4e7a96ecddd31a26f353509de976bcc9e397
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Volker Krause <volker.krause@kdab.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The software renderers dirty region calculation is done in integral logical
coordinates, which leads to quite some trouble when handling scene graph
elements with fractional coordinates (used by WebEngine for example).
The optimal solution would probably be to either use integral physical
coordinates or floating point logical coordinates, however this would seem to
require substantial changes to QPainter and QBackingStore and so on. So, this
patch instead changes the calculation to use something like interval arithmetic:
instead of just rounding each logical coordinate to the nearest integer the
renderer now uses (very carefully) both the upper and lower boundaries to make
sure that the dirty regions always err on the side of caution.
I expect this change to make rendering slower but only in situations where
previously there would be rendering errors.
Task-number: QTBUG-60393
Change-Id: I7f8e7d2739c810328c841130df9c1c7332439447
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
| |
Also port remaining foreach to 'range for'.
Change-Id: I20296bb3bb6d63f144ebddaba02cabeb16b7d734
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Calling grabWindow recurses (since that is implemented via
QQuickRenderControl::grab...) so it's not an option. Instead,
call directly in the software renderer implementation.
Fix also the size of the offscreen QQuickWindow when using QQuickWidget
in combination with the software backend.
Change-Id: I857a2cc0aebbbaa5d52d809aeaec37c15b0787b9
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When rendering into QBackingStores, it is important to let the
backingstore know what region you intended to paint into before you
start rendering. Previously we were calling QBackingStore::beginPaint on
the whole window area, but then only rendering and flushing for a subset
of that area. This causes issues on platforms that depend on
QBackingStore::beginPaint to be all area that will be repainted before
the next flush, so that they can for example clear those areas.
This change required a bit of extra plumbing in the Software Renderer,
but now it is possible to calculate the area that will be repainted
before painting it, and pass that region to QBackingStore::beginPaint().
Change-Id: I90be1916ebbe8fc182cd13246bb6690cc7e16d27
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previous behavior was to always subtract the current bounding rect of
items when calculating the previous dirty region. When you remove a
node though, there is no current bounding rect because the item no
longer exists. The last valid boundingRect was use instead, which led
to the previous bounding rect to not get marked as dirty when the node
was removed.
Change-Id: Ic1a4f872d4d46125b06e2588aae695b8ff67d0fd
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|
|
|
The 2D renderer will now become a built-in adaptation of scenegraph that
should always be available to fallback to when there are no other
renders available. So rather than be an external plugin, now it is a
built in adaptation.
Change-Id: Ifa02fd50f3085ad1e6f1a73c3ce1e1825b677cc7
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
|
