LibreOffice Module canvas (master) 1
Public Member Functions | List of all members
canvas::ISurfaceProxyManager Struct Referenceabstract

Manager interface, which handles surface proxy objects. More...

#include <isurfaceproxymanager.hxx>

Public Member Functions

virtual ~ISurfaceProxyManager ()
 
virtual std::shared_ptr< ISurfaceProxycreateSurfaceProxy (const std::shared_ptr< IColorBuffer > &pBuffer) const =0
 Create a surface proxy for a color buffer. More...
 

Detailed Description

Manager interface, which handles surface proxy objects.

Typically, each canvas instantiation has one SurfaceProxyManager object, to handle their surfaces. Surfaces itself are opaque objects, which encapsulate a framebuffer to render upon, plus an optional (possibly accelerated) texture.

Definition at line 38 of file isurfaceproxymanager.hxx.

Constructor & Destructor Documentation

◆ ~ISurfaceProxyManager()

virtual canvas::ISurfaceProxyManager::~ISurfaceProxyManager ( )
inlinevirtual

Definition at line 40 of file isurfaceproxymanager.hxx.

Member Function Documentation

◆ createSurfaceProxy()

virtual std::shared_ptr< ISurfaceProxy > canvas::ISurfaceProxyManager::createSurfaceProxy ( const std::shared_ptr< IColorBuffer > &  pBuffer) const
pure virtual

Create a surface proxy for a color buffer.

The whole idea is build around the concept that you create some arbitrary buffer which contains the image data and tell the texture manager about it. From there on you can draw into this image using any kind of graphics api you want. In the technical sense we allocate some space in local videomemory or AGP memory which will be filled on demand, which means if there exists any rendering operation that needs to read from this memory location. This method creates a logical hardware surface object which uses the given color buffer as the image source. Internally this texture may even be distributed to several real hardware surfaces.


The documentation for this struct was generated from the following file: