Cogl.Display¶

Subclasses:: None

Methods¶

Inherited:: Cogl.Object (2)

class	`new` (renderer, onscreen_template)
	`get_renderer` ()
	`set_onscreen_template` (onscreen_template)
	`setup` ()

Virtual Methods¶

None

Fields¶

None

Class Details¶

class Cogl.Display¶

Bases:: Cogl.Object
Abstract:: No

classmethod new(renderer, onscreen_template)¶

Parameters:

renderer (Cogl.Renderer) – A Cogl.Renderer
onscreen_template (Cogl.OnscreenTemplate) – A Cogl.OnscreenTemplate

Returns:

A newly allocated Cogl.Display object in a mutable configuration mode.

Return type:

Cogl.Display

Explicitly allocates a new Cogl.Display object to encapsulate the common state of the display pipeline that applies to the whole application.

Many applications don’t need to explicitly use Cogl.Display.new() and can just jump straight to Cogl.Context.new() and pass a None display argument so Cogl will automatically connect and setup a renderer and display. A display can only be made for a specific choice of renderer which is why this takes the renderer argument.

A common use for explicitly allocating a display object is to define a template for allocating onscreen framebuffers which is what the onscreen_template argument is for, or alternatively you can use Cogl.Display.set_onscreen_template().

When a display is first allocated via Cogl.Display.new() it is in a mutable configuration mode. It’s designed this way so we can extend the apis available for configuring a display without requiring huge numbers of constructor arguments.

When you have finished configuring a display object you can optionally call Cogl.Display.setup() to explicitly apply the configuration and check for errors. Alternaitvely you can pass the display to Cogl.Context.new() and Cogl will implicitly apply your configuration but if there are errors then the application will abort with a message. For simple applications with no fallback options then relying on the implicit setup can be fine.

New in version 1.10.

get_renderer()¶

Returns:: The associated Cogl.Renderer
Return type:: Cogl.Renderer

Queries the Cogl.Renderer associated with the given self.

New in version 1.10.

set_onscreen_template(onscreen_template)¶

Parameters:: onscreen_template (Cogl.OnscreenTemplate) – A template for creating Cogl.Onscreen framebuffers

Specifies a template for creating Cogl.Onscreen framebuffers.

Depending on the system, the constraints for creating Cogl.Onscreen framebuffers need to be known before setting up a Cogl.Display because the final setup of the display may constrain how onscreen framebuffers may be allocated. If Cogl knows how an application wants to allocate onscreen framebuffers then it can try to make sure to setup the display accordingly.

New in version 1.16.

setup()¶

Raises:: GLib.Error
Returns:: Returns True if there was no error, else it returns False and returns an exception via error.
Return type:: int

Explicitly sets up the given self object. Use of this api is optional since Cogl will internally setup the display if not done explicitly.

When a display is first allocated via Cogl.Display.new() it is in a mutable configuration mode. This allows us to extend the apis available for configuring a display without requiring huge numbers of constructor arguments.

Its possible to request a configuration that might not be supportable on the current system and so this api provides a means to apply the configuration explicitly but if it fails then an exception will be returned so you can handle the error gracefully and perhaps fall back to an alternative configuration.

If you instead rely on Cogl implicitly calling Cogl.Display.setup() for you then if there is an error with the configuration you won’t get an opportunity to handle that and the application may abort with a message. For simple applications that don’t have any fallback options this behaviour may be fine.

New in version 1.10.