fix(render): one fence per frame for the vertex ring; two qt6 adapter fixes
The persistent-mapped instance ring had three slots and recorded a fence per upload, so a frame recycled a slot whose fence was recorded a few draws earlier *in that same frame*: from the fourth of the demos' nine uploads on, each one waited on the frame's own work. It is free on a driver that retires draws promptly (the GLFW host, 1.07 ms/frame) and ~4 ms of the Qt widget's 7.11 ms under llvmpipe, and it grows with the trace and cursor counts this library exists for. * The ring grows to cover a frame's upload count, the frame's write cursor is the ring index (so a frame writes 0, 1, 2, ... and never a slot twice), one fence is recorded after the frame's last draw, and the only wait is at the start of the next frame. A wait that times out, or a slot written with no fence ever recorded behind it, drops the store to the orphan path -- the treatment a refused fence already had -- so nothing is ever written into storage the GPU may still be reading. * New test-only counters (PLOT_RING_STATS, the PLOT_PYRAMID_COUNT_* pattern: free functions, no member, so no consumer's layout changes) pin a frame's upload and wait counts. The new tests assert the frame's slot offsets are distinct, that the ring grew past its floor to cover the frame, and that a frame waits at most once per store -- read from the counters and from glClientWaitSync itself. * qt6: print the unresolved entry-point names before the load-failure branch, which used to return first and leave the one failure this widget can have reporting nothing but a generic message. * qt6: the cached pointer anchor is now in logical pixels and a move's delta is the logical difference scaled by the DPR in effect, so a scale change between two move events (the window dragged onto another monitor mid-drag) is no longer a cross-scale jump applied as a pan. The anchor moved into a toolkit-free unit (adapters/qt6/qt_pointer.hpp) with its own test. GLFW demo headless: 1.07 -> 0.73 ms/frame. Qt widget under xvfb/llvmpipe: 7.1 -> 3.8 ms at dpr 1.0, 6.7 -> 3.6 ms at 1.25, with both upload paths still rendering and the demo's scripted pan/box-zoom checks passing at both scales.
This commit is contained in:
1 parent
1ee2dd9c3d
commit
3c0e7763ab
13 files changed
+626
-113
No files matched your search
@@ -18,6 +18,7 @@
|
||||
#include <plot/math/vec2.hpp>
|
||||
#include <plot/plot/plot.hpp>
|
||||
#include <plot/render/renderer.hpp>
|
||||
#include <qt6/qt_pointer.hpp>
|
||||
|
||||
#include <QOpenGLFunctions>
|
||||
#include <QOpenGLWidget>
|
||||
@@ -80,14 +81,21 @@ namespace plot::qt {
|
||||
/// * the viewport handed to the plot is `round(width() * dpr)` x
|
||||
/// `round(height() * dpr)` (rounded, not truncated, so the last column of the
|
||||
/// FBO is inside the plot), and
|
||||
/// * every pointer, wheel and key anchor is multiplied by the same
|
||||
/// `devicePixelRatioF()` before it reaches the controller, deltas included.
|
||||
/// * every pointer and wheel position is multiplied by the same
|
||||
/// `devicePixelRatioF()` before it reaches the controller.
|
||||
///
|
||||
/// `device_viewport()` and `to_device()` are the only two places that mapping
|
||||
/// exists, so the viewport and the input cannot disagree -- and they must not: a
|
||||
/// mismatch renders correctly but pans by the wrong amount, which is invisible on
|
||||
/// an unscaled display and wrong on every other one.
|
||||
///
|
||||
/// The *anchor* a move's delta is measured from is the one thing kept in logical
|
||||
/// pixels: `devicePixelRatioF()` can change between two move events, and the delta
|
||||
/// is then a logical difference scaled by the ratio in effect now, never the
|
||||
/// difference of two device positions taken at different ratios (see
|
||||
/// `PointerAnchor`). A drag that crosses onto a display with another scale factor
|
||||
/// therefore pans by the distance the pointer moved, not by a cross-scale jump.
|
||||
///
|
||||
/// ## Input
|
||||
///
|
||||
/// Qt reports levels and edges directly (`QMouseEvent` press/release are edges,
|
||||
@@ -174,9 +182,10 @@ class PlotWidget : public QOpenGLWidget, protected QOpenGLFunctions {
|
||||
/// The widget's rectangle in device pixels: the plot's viewport, and the size
|
||||
/// of the framebuffer the frame is drawn into.
|
||||
Rect device_viewport() const noexcept;
|
||||
/// A Qt position (logical widget pixels) in device pixels. The one place the
|
||||
/// input mapping exists, so every event is scaled by the same factor the
|
||||
/// viewport is.
|
||||
/// A Qt position (logical widget pixels) in device pixels. The one place a
|
||||
/// pointer position is mapped, so everything the controller sees is scaled by
|
||||
/// the same factor the viewport is -- a move's *delta*, whose ratio can change
|
||||
/// between two events, is scaled by `PointerAnchor` instead.
|
||||
Vec2 to_device(const QPointF& p) const noexcept;
|
||||
/// Translates one mouse event and hands it to the controller. `pressed` and
|
||||
/// `released` are the transitions Qt reports on the event itself.
|
||||
@@ -191,11 +200,10 @@ class PlotWidget : public QOpenGLWidget, protected QOpenGLFunctions {
|
||||
FrameFn frame_;
|
||||
Status init_status_;
|
||||
|
||||
/// Last pointer position in device pixels: the deltas the controller pans with
|
||||
/// are the movement since the previous event, which Qt does not report.
|
||||
bool have_pointer_ = false;
|
||||
f32 last_x_ = 0.0f;
|
||||
f32 last_y_ = 0.0f;
|
||||
/// The position a move's delta is measured from, in **logical** pixels: Qt
|
||||
/// reports no delta of its own, and the ratio can change between two events
|
||||
/// (see `PointerAnchor` for why the anchor must not be device pixels).
|
||||
PointerAnchor anchor_;
|
||||
|
||||
u64 frames_ = 0;
|
||||
f32 last_frame_ms_ = 0.0f;
|
||||
|
||||
Reference in new issue
Block a user