summaryrefslogtreecommitdiff
path: root/src/apps/qcam/cam_select_dialog.h
diff options
context:
space:
mode:
authorRobert Mader <robert.mader@collabora.com>2024-09-26 23:07:39 +0200
committerKieran Bingham <kieran.bingham@ideasonboard.com>2024-09-27 16:40:15 +0100
commitabe2ec64f9e4e97bbdfe3a50372611bd7b5315c2 (patch)
tree4ad34c713d45ef67e5695400cc1da946d55c7da0 /src/apps/qcam/cam_select_dialog.h
parent6c0aefdaf92b62e77bdc3b8add2b8107e50a5544 (diff)
pipeline: simple: Increase buffer count to four
Which is not only what many other pipeline handlers use, but also a good lower limit when dealing with DRM and similar APIs. Even Mesas EGL and Vulkan WSI implementations use for the reason outlined in mesa commit 992a2dbba80aba35efe83202e1013bd6143f0dba: > When the compositor is directly scanning out from the application's buffer it > may end up holding on to three buffers. These are the one that is is currently > scanning out from, one that has been given to DRM as the next buffer to flip > to, and one that has been attached and will be given to DRM as soon as the > previous flip completes. When we attach a fourth buffer to the compositor it > should replace that third buffer so we should get a release event immediately > after that. This patch therefore also changes the number of buffer slots to 4 > so that we can accomodate that situation. Given the popularity of this buffer number the bump should be unlikely to cause problems. At the same time it may help with performance or even work around glitches. The previous number was introduced in commit a8964c28c80fb520ee3c7b10143371081d41405a without mentioning a specific reason against the change at hand. Signed-off-by: Robert Mader <robert.mader@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Diffstat (limited to 'src/apps/qcam/cam_select_dialog.h')
0 files changed, 0 insertions, 0 deletions