Fix bad vkResetFences placement in triangle chapter

Overv · Overv · commit 0dd14590b9eb · 2019-11-03T13:35:45.000+01:00
diff --git a/code/15_hello_triangle.cpp b/code/15_hello_triangle.cpp
@@ -642,7 +642,6 @@ class HelloTriangleApplication {
 
     void drawFrame() {
         vkWaitForFences(device, 1, &inFlightFences[currentFrame], VK_TRUE, UINT64_MAX);
-        vkResetFences(device, 1, &inFlightFences[currentFrame]);
 
         uint32_t imageIndex;
         vkAcquireNextImageKHR(device, swapChain, UINT64_MAX, imageAvailableSemaphores[currentFrame], VK_NULL_HANDLE, &imageIndex);
@@ -668,6 +667,8 @@ class HelloTriangleApplication {
         submitInfo.signalSemaphoreCount = 1;
         submitInfo.pSignalSemaphores = signalSemaphores;
 
+        vkResetFences(device, 1, &inFlightFences[currentFrame]);
+
         if (vkQueueSubmit(graphicsQueue, 1, &submitInfo, inFlightFences[currentFrame]) != VK_SUCCESS) {
             throw std::runtime_error("failed to submit draw command buffer!");
         }
diff --git a/en/03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.md b/en/03_Drawing_a_triangle/03_Drawing/02_Rendering_and_presentation.md
@@ -583,6 +583,22 @@ void drawFrame() {
 }
 ```
 
+Because we now have more calls to `vkWaitForFences`, the `vkResetFences` call should be **moved**. It's best to simply call it right before actually using the fence:
+
+```c++
+void drawFrame() {
+    ...
+
+    vkResetFences(device, 1, &inFlightFences[currentFrame]);
+
+    if (vkQueueSubmit(graphicsQueue, 1, &submitInfo, inFlightFences[currentFrame]) != VK_SUCCESS) {
+        throw std::runtime_error("failed to submit draw command buffer!");
+    }
+
+    ...
+}
+```
+
 We've now implemented all the needed synchronization to ensure that there are no more than two frames of work enqueued and that these frames are not accidentally using the same image. Note that it is fine for other parts of the code, like the final cleanup, to rely on more rough synchronization like `vkDeviceWaitIdle`. You should decide on which approach to use based on performance requirements.
 
 To learn more about synchronization through examples, have a look at [this extensive overview](https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples#swapchain-image-acquire-and-present) by Khronos.
diff --git a/en/03_Drawing_a_triangle/04_Swap_chain_recreation.md b/en/03_Drawing_a_triangle/04_Swap_chain_recreation.md
@@ -168,19 +168,6 @@ If the swap chain turns out to be out of date when attempting to acquire an
 image, then it is no longer possible to present to it. Therefore we should
 immediately recreate the swap chain and try again in the next `drawFrame` call.
 
-However, if we abort drawing at this point then the fence will never have
-been submitted with `vkQueueSubmit` and it'll be in an unexpected state when we
-try to wait for it later on. We could recreate the fences as part of swap chain
-recreation, but it's easier to move the `vkResetFences` call:
-
-```c++
-vkResetFences(device, 1, &inFlightFences[currentFrame]);
-
-if (vkQueueSubmit(graphicsQueue, 1, &submitInfo, inFlightFences[currentFrame]) != VK_SUCCESS) {
-    throw std::runtime_error("failed to submit draw command buffer!");
-}
-```
-
 You could also decide to do that if the swap chain is suboptimal, but I've
 chosen to proceed anyway in that case because we've already acquired an image.
 Both `VK_SUCCESS` and `VK_SUBOPTIMAL_KHR` are considered "success" return codes.
