When I zoom elements backed by FramebufferWidget
, they draw as if the transformation matrix is being concatenated in the wrong order. It ends up looking like this: [Edit: fixed link]
Once I stop zooming, everything draws correctly.
I don’t doubt that I’m doing something wrong, but I haven’t been able to track it down. Since it only happens while I’m zooming, debugging is difficult.
If someone else has run into a bug like this, I’m interested in what you did to track it down and fix it.
The FramebufferWidget
is used like this:
struct DisplayWidget : Widget {
void draw(const DrawArgs& ) override {
...
Widget::draw(args);
}
};
struct Buffer : Widget {
FramebufferWidget* fb;
Buffer() {
fb = new FramebufferWidget();
this->addChild(fb);
auto display = new DisplayWidget();
fb->addChild(display);
}
};
struct MyWidget : ModuleWidget {
Buffer* buffer;
MyWidget(Module* module) {
buffer = new Buffer();
}
};
[Edit #2] I tried to dirty the FramebufferWidget
on every redraw triggered by the zoom, but that didn’t help. After some more debugging, I determined that FramebufferWidget::step
is not calling FramebufferWidget::drawFrameBuffer
because
APP->window->isFrameOverdue()
returns true most of the time while zooming. Setting "frameRateLimit": 0.0
in settings.json
improves things, but then the frame buffer creation lags enough that the drawing appears out of sync.
When I have time, I’ll rewrite FramebufferWidget::step
to draw directly and avoid creating a frame buffer when it doesn’t have time to draw everything…
[Edit #3] … or I’ll rewrite my module so that while zooming is underway, the Widgets are drawn immediately without a backing FramebufferWidget
. I think I can do this by adding the widgets twice, and making only the direct one or the FramebufferWidget
one visible …