From 6384ff3ee7cf4888df772e293d66a24bb0f415d7 Mon Sep 17 00:00:00 2001
From: Thomas Harte <thomas.harte@gmail.com>
Date: Sun, 9 Aug 2020 21:17:51 -0400
Subject: [PATCH] Add fix for `data_type_size_` for owners that don't change
texture pointer upon new modals.
---
Outputs/ScanTargets/BufferingScanTarget.cpp | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Outputs/ScanTargets/BufferingScanTarget.cpp b/Outputs/ScanTargets/BufferingScanTarget.cpp
index 96b9f5bf1..b14f6f6e1 100644
--- a/Outputs/ScanTargets/BufferingScanTarget.cpp
+++ b/Outputs/ScanTargets/BufferingScanTarget.cpp
@@ -264,7 +264,6 @@ void BufferingScanTarget::set_write_area(uint8_t *base) {
std::lock_guard lock_guard(producer_mutex_);
#endif
write_area_ = base;
- data_type_size_ = Outputs::Display::size_for_data_type(modals_.input_data_type);
write_pointers_ = submit_pointers_ = read_pointers_ = PointerSet();
allocation_has_failed_ = true;
vended_scan_ = nullptr;
@@ -340,6 +339,12 @@ const Outputs::Display::ScanTarget::Modals *BufferingScanTarget::new_modals() {
return nullptr;
}
modals_are_dirty_ = false;
+
+ // MAJOR SHARP EDGE HERE: assume that because the new_modals have been fetched then the caller will
+ // now ensure their texture buffer is appropriate. They might provide a new pointer and might now.
+ // But either way it's now appropriate to start treating the data size as implied by the data type.
+ data_type_size_ = Outputs::Display::size_for_data_type(modals_.input_data_type);
+
return &modals_;
}