[libcamera-devel] Docs about buffers

Dorota Czaplejewicz dorota.czaplejewicz at puri.sm
Thu Nov 18 18:06:23 CET 2021


On Thu, 18 Nov 2021 15:32:23 +0000
Kieran Bingham <kieran.bingham at ideasonboard.com> wrote:

> I would suspect that the move to make FrameBuffer 'extensible' hasn't
> moved all possible things to the private implementation yet. Cancelling
> a buffer shouldn't be exposed from the public API.
> 
> If you'd like to fix this as an exercise to help you learn the code
> base, I'll let you fix this. If you don't want to - I'll fix it and
> submit a patch. But this might be an 'easy' task that might help you dig
> deeper around the codebase, so I don't want to take the fix away from
> you if you want it.
> 
> FrameBuffer::cancel() should likely be moved to
> FrameBuffer::Private::cancel().
> 
> You'll see that there is an 'include/libcamera/internal/framebuffer.h'
> with the 'private' implementation, while
> 'include/libcamera/framebuffer.h' has the public API version.

I'll take it for the learning experience.

From what I'm seeing, the intention is to have the public class final, and the private class extensible, regardless of member visibility.

I'm not familiar with this pattern, so is the plan to move all public API members of private visibility to the private class? I don't see a need for them after all, as they will never be accessible from interfacing code.

I'm asking because ::cancel references MetaData, which is currently part of the public API too, and the ::Private class holds no reference to it.

Cheers,
Dorota
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20211118/d1845a0f/attachment.sig>


More information about the libcamera-devel mailing list