1. 14 May, 2020 3 commits
  2. 13 May, 2020 3 commits
  3. 12 May, 2020 7 commits
  4. 11 May, 2020 4 commits
  5. 08 May, 2020 4 commits
  6. 07 May, 2020 4 commits
    • Laszlo Agocs's avatar
      rhi: vulkan: Fix calling finish() twice with some copy commands in-between · 8cdc9ac5
      Laszlo Agocs authored
      
      
      The native command buffer handle was not updated, so the subsequent
      finish() call attempted to record an invalid VkCommandBuffer. The
      problem was not present with offscreen frames, only when finish() is
      called with a swapchain-based frame active.
      
      Task-number: QTBUG-84066
      Change-Id: I9c4cb701c3dbbc28f237d6ae1cbf65aafd1fa95f
      Reviewed-by: default avatarChristian Strømme <christian.stromme@qt.io>
      8cdc9ac5
    • Shawn Rutledge's avatar
      Remove QScreen::orientationUpdateMask · 3e12951c
      Shawn Rutledge authored
      
      
      It simplifies the API and reduces surprise to have rotation working by default.
      On Android, the manifest specifies which orientations the application has
      been designed to support; on iOS, it is controlled via the
      UISupportedInterfaceOrientations property list key.
      In addition, QWindow::contentOrientation() is another way to give
      a hint to the window manager, or on iOS to directly control whether
      the window's rotation is locked or not.
      
      Task-number: QTBUG-35427
      Task-number: QTBUG-38576
      Task-number: QTBUG-44569
      Task-number: QTBUG-51012
      Task-number: QTBUG-83055
      Change-Id: Ieed818497f686399db23813269af322bfdd237af
      Reviewed-by: default avatarRichard Moe Gustavsen <richard.gustavsen@qt.io>
      3e12951c
    • Laszlo Agocs's avatar
      rhi: Correct another scissor/viewport clamping problem · 0acab3c1
      Laszlo Agocs authored
      
      
      When x or y are >= the width or height of the render target, then the
      width or height of the scissor/viewport rect is zero, no further logic
      is needed.
      
      This is different from the case of x or y being negative, because then
      there is still a chance that there is an in-bounds area (if width or
      height are large enough).
      
      It is important to make this check based on the original value of x
      and y, not the clamped ones. Otherwise we end up with a 1 pixel wide
      region even when the expected result is a width or height of 0.
      
      Previously the incorrect subtraction of 1 in the final clamping of w and h
      masked this, but once that is fixed, the issue fixed here becomes visible
      in the cubemap_scissor manual test.
      
      Change-Id: I3d4b0a163a16aa1116b1e838fa95c0faf7b56a3d
      Reviewed-by: default avatarEirik Aavitsland <eirik.aavitsland@qt.io>
      0acab3c1
    • Eirik Aavitsland's avatar
      RHI: fix off-by-one clipping · f116221a
      Eirik Aavitsland authored
      
      
      In cases where qrhi_toTopLeftRenderTargetRect() would clip the width or height
      to the available space, it would subtract 1 from the result, leading to
      painting errors.
      
      Fixes: QTBUG-83928
      Change-Id: I65d23151d838386b516ded0588702bc0bf4c0d93
      Reviewed-by: default avatarJonas Karlsson <jonas.karlsson@qt.io>
      Reviewed-by: default avatarLaszlo Agocs <laszlo.agocs@qt.io>
      f116221a
  7. 06 May, 2020 3 commits
  8. 05 May, 2020 12 commits