| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
EntityRenderCommandData would only be released in a separate job than the one
it was allocated in. However this would only happen if there was at least a
single renderable objects after filtering. In case there was no renderable
following filtering, the EntityRenderCommandData was leaked.
To fix the issue and make it less error prone, we now switch to using shared
pointers to avoid having to handle all possible leak cases with raw pointers.
Change-Id: I842d50d2b35ebba8303f6d6c4e72a2427ce31da3
Reviewed-by: Mike Krus <mike.krus@kdab.com>
|
| |
|
|
|
| |
Change-Id: Ib290491476b083e6aa4cff5c112a802c4e198987
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, we can generate the RenderCommands once and reuse them in
subsequent frames only updating the uniforms. We still have to copy the
RenderCommands as the renderer renders while we start preparing the next frame.
This is still faster than regenerating them entirely.
Regenerating the entire commands will happen only when FrameGraph or Scene
structure changes. That should rarely be happening on a per frame basis.
Next step could be to look at how to only update commands for Entity with Parameters
that have changed.
Change-Id: I202870850a46fcd3946f81bffddb7027d192f374
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
|
| |
|
|
|
|
|
|
| |
Some values where overridden in Renderer::prepareSubmission so no point
in spending time setting them in the first place
Change-Id: Iceea0cbe044b883d0797aebd7487f8f6b29ac542
Reviewed-by: Mike Krus <mike.krus@kdab.com>
|
|
|
This is another step toward isolating the renderer from the render aspect
Change-Id: I4031675b961d6645b65bbe05cf62d150993038b0
Task-number: QTBUG-61151
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
|
