Eventually we might want to have an XCB-based EGL winsys. We already
have xlib-specific API in CoglRenderer (eg, to set a foreign display)
so the application needs to be able to specifically select between XCB
and XLIB.
This also removes the POWERVR part while renaming
COGL_HAS_EGL_PLATFORM_POWERVR_X11_SUPPORT to
COGL_HAS_EGL_PLATFORM_XLIB_SUPPORT because the winsys is equally
applicable to Mesa.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This moves all of the code specific to the Android platform out of
cogl-winsys-egl. It is completely untested apart from that it
compiles using a dummy android/native_window.h header.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This moves all of the code specific to the gdl winsys out of
cogl-winsys-egl. It is completely untested apart from that it
compiles.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The egl_surface_width/height properties in CoglDisplayEGL were
accidentally being conditionally defined depending on KMS
support. They are not necessary because CoglDisplayKMS also already
stores the width/height and this was just copied over to the EGL
dipslay.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The GLX and EGL winsys backends had a check for when onscreen==NULL
in which case they would instead try to bind the dummy surface. This
wouldn't work however because it would have already crashed by that
point when it tried to get the Cogl context out of the onscreen. The
function needs a bit of refactoring before it could support this but
presumably nothing is relying on this anyway because it wouldn't work
so for now we can just remove it.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
CoglXlibDisplay just contained one member called dummy_xwin. This was
not shared outside of the respective winsys's so I don't think it
really makes sense to have a separate shared struct for it. It seems
more like an implementation detail that is specific to the winsys
because for example it may be that the EGL winsys could use the
surfaceless extension and not bother with a dummy window. This will
also make it easier to factor out the Xlib-specific data in
CoglDisplayEGL to the platform data.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Previously the Xlib renderer data was meant to be the first member of
whatever the winsys data is. This doesn't work well for the EGL winsys
because it only needs the Xlib data if the X11 platform is used. The
Xlib renderer data is now instead created on demand and connected to
the object using cogl_object_set_user_data. There is a new function to
get access to it.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Instead of having #ifdefs to hook into the normal EGL winsys, the KMS
winsys now overrides any winsys functions that it wants. Where the
winsys wants to hook into a point within a function provided by the
EGL winsys there is a EGL-platform vtable which gets set on the EGL
renderer data during renderer_connect. The KMS-specific data on all of
the structures is now allocated separately by the KMS winsys and is
pointed to by a new 'platform' pointer in the EGL data.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The #ifdefs in cogl-winsys-egl have been changed so that they
additionally check renderer->winsys_vtable->id for the corresponding
winsys ID so that multiple EGL platforms can be enabled.
The is a stop-gap solution until we can move all of the EGL platforms
into their own winsys files with overrides of the EGL vtable. However
with this approach we can move one platform at a time which will make
it easier.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Instead of just having an "EGL" renderer, there is now a separate
winsys for each platform. Currently they just directly copy the vtable
for the EGL platform so it is still only possible to have one EGL
platform compiled into Cogl. However the intention is that the
winsys-specific code for each platform will be moved into override
functions in the corresponding platform winsys.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Requests for the shell to manipulate it's state for the surface are now
abstracted through a wl_shell_surface object rather through wl_shell as
before.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
There are three separate EGL_KHR_surfaceless_* extensions depending on
which GL API is being used so we should probably check the right one
depending on which driver Cogl has selected.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
There were two problems stopping the KMS winsys from working with a
GLES2 driver:
• When creating the EGL context, it was missing the attribute to
select the client version so it would end up with the GLES1 API.
• When creating the depth buffer for the framebuffer it was using
GL_DEPTH_COMPONENT but only GL_DEPTH_COMPONENT16 is supported on
GLES. cogl-framebuffer already unconditionally uses this so it
probably makes sense to do the same here.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The compositor side wayland support enabling us to create textures from
wayland buffers needed updating since visuals were removed from the
wayland protocol.
This also fixes the #ifdef guards for the bind_wayland_display extension
in cogl-winsys-egl-feature-functions.h since it was mistakenly checking
that client-side wayland support had been enabled which won't be the
case.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Since the wayland protocol doesn't currently provide a way to
retrospectively query the interfaces that get notified when a client
first connects then when using a foreign display with Cogl then we also
need api for telling cogl what compositor and shell objects to use. We
already had api for setting a foreign compositor so this patch just adds
api for setting a foreign shell.
This patch also adds documentation for all the wayland specific apis.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
For some reason the EGL spec says that the surface passed to
eglSwapBuffers must be bound as the current surface for the swap to
work. Mesa validates that this is the case and returns an error from
the swap buffers call if not.
https://bugzilla.gnome.org/show_bug.cgi?id=665604
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Previously the cost of _cogl_framebuffer_state_flush() would always
scale by the total amount of state tracked by CoglFramebuffer even in
cases where we knew up-front that we only wanted to flush a subset of
the state or in cases where we requested to flush the same framebuffer
multiple times with no changes being made to the framebuffer.
We now track a set of state changed flags with each framebuffer and
track the current read/draw buffers as part of the CoglContext so that
we can quickly bail out when asked to flush the same framebuffer
multiple times with no changes.
_cogl_framebuffer_flush_state() now takes a mask of the state that we
want to flush and the implementation has been redesigned so that the
cost of checking what needs to be flushed and flushing those changes
now scales by how much state we actually plan to update.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
When saving the CRTC we were trying to use a struct member for the encoder
that wasn't valid at that point in time - instead use the local variable.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
We were missing various platform header includes in
cogl-winsys-egl-private.h when building support for non KMS egl
platforms.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
A small, pedantic change to remove the use of redundant gint and GLuint
types instead of int and unsigned int.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds a check for the EGL_KHR_surfaceless_opengl extension which we
depend on for being able to MakeCurrent (NO_SURFACE) as well as create a
context without and EGLConfig.
Reviewed-by: Rob Bradford <rob@linux.intel.com>
Since _cogl_winsys_kms_display_setup was basically just calling
setup_kms() it made sense to fold the code of setup_kms() back into the
_cogl_winsys_kms_display_setup() function.
Reviewed-by: Rob Bradford <rob@linux.intel.com>
So that the various internal Cogl*EGL typedefs can be available to
cogl-winsys-kms.c this moves them into cogl-winsys-egl-private.h
Reviewed-by: Rob Bradford <rob@linux.intel.com>
To start with this backend only supports creating a single CoglOnscreen
framebuffer and will automatically set is up to display fullscreen on
the first suitable crtc it can find.
To compile this backend - get some dribbly black candles, sacrifice a
goat and configure with: --enable-kms-egl-platform
Note: There is currently a problem with using GLES2 with this winsys
so you need to run with EGL_DRIVER=gl
Note: If you have problems with mesa crashing in XCB during
eglInitialize then you may need to explicitly run with EGL_PLATFORM=gbm
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Deal with c99ism... I know it's not pretty, but it is the way
to go with non-c99 compilers. That's life...
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This moves the POPCOUNTL macro from cogl-winsys-glx to cogl-util and
renames it to _cogl_util_popcountl so that it can be used in more
places. The fallback function for when the GCC builtin is not
available has been replaced with an 8-bit lookup table because the
HAKMEM implementation doesn't look like it would work when longs are
64-bit so it's not suitable for a general purpose function on 64-bit
architectures. Some of the pages regarding population counts seem to
suggest that using a lookup table is the fastest method anyway.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This change is one logical update to update the Wayland support. This
comprises of the following parts:
* Binding to both the shell and compositor global objects - necessary since
the API for setting top level status moved to the wl_shell interface
* The Wayland visual API went away and instead you setup the EGL surface
appropriately
* The message handling was refined to reflect the current behaviour - now
obsolete comments were removed and new comments updated
Reviewed-by: Robert Bragg <robert@linux.intel.com>
There was a comment implying that if a rgba config has been requested
but no suitable config was found then we would automatically fall back
to an rgb config instead. Actually if no rgba visual is found we simply
fail without any automatic fall back because Cogl is not in a good
position to judge if automatic fall backs are acceptable for higher
level apis such as clutter.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Xlib headers define many trivially named objects which can later cause
name collision problems when only cogl.h header is included in a program
or library. Xlib headers are now only included through including the
standalone header cogl-xlib.h.
https://bugzilla.gnome.org/show_bug.cgi?id=661174
Reviewed-by: Robert Bragg <robert@linux.intel.com>
It's useful to be able to query back the number of
point_samples_per_pixel that may have previously be chosen using
cogl_framebuffer_set_samples_per_pixel().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This exposes CoglTextureRectangle in the experimental cogl 2.0 api. For
now we just expose a single constructor;
cogl_texture_rectangle_new_with_size() but we can add more later.
This is part of going work to improve our texture apis with more
emphasis on providing low-level access to the varying semantics of
different texture types understood by the gpu instead of only trying to
present a lowest common denominator api.
CoglTextureRectangle is notably useful for never being restricted to
power of two sizes and for being sampled with non-normalized texture
coordinates which can be convenient for use a lookup tables in glsl due
to not needing separate uniforms for mapping normalized coordinates to
texels. Unlike CoglTexture2D though rectangle textures can't have a
mipmap and they only support the _CLAMP_TO_EDGE wrap mode.
Applications wanting to use CoglTextureRectangle should first check
cogl_has_feature (COGL_FEATURE_ID_TEXTURE_RECTANGLE).
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Since we've had several developers from admirable projects say they
would like to use Cogl but would really prefer not to pull in
gobject,gmodule and glib as extra dependencies we are investigating if
we can get to the point where glib is only an optional dependency.
Actually we feel like we only make minimal use of glib anyway, so it may
well be quite straightforward to achieve this.
This adds a --disable-glib configure option that can be used to disable
features that depend on glib.
Actually --disable-glib doesn't strictly disable glib at this point
because it's more helpful if cogl continues to build as we make
incremental progress towards this.
The first use of glib that this patch tackles is the use of
g_return_val_if_fail and g_return_if_fail which have been replaced with
equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This factors out the CoglOnscreen code from cogl-framebuffer.c so we now
have cogl-onscreen.c, cogl-onscreen.h and cogl-onscreen-private.h.
Notably some of the functions pulled out are currently namespaced as
cogl_framebuffer but we know we are planning on renaming them to be in
the cogl_onscreen namespace; such as cogl_framebuffer_swap_buffers().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
CoglMetaTexture is an interface for dealing with high level textures
that may be comprised of one or more low-level textures internally. The
interface allows the development of primitive drawing APIs that can draw
with high-level textures (such as atlas textures) even though the
GPU doesn't natively understand these texture types.
There is currently just one function that's part of this interface:
cogl_meta_texture_foreach_in_region() which allows an application to
resolve the internal, low-level textures of a high-level texture.
cogl_rectangle() uses this API for example so that it can easily emulate
the _REPEAT wrap mode for textures that the hardware can't natively
handle repeating of.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Currently features are represented as bits in a 32bit mask so we
obviously can't have more than 32 features with that approach. The new
approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks
without a size limit and we change the public api to accept individual
feature enums instead of a mask. This way there is no limit on the
number of features we can add to Cogl.
Instead of using cogl_features_available() there is a new
cogl_has_feature() function and for checking multiple features there is
cogl_has_features() which takes a zero terminated vararg list of
features.
In addition to being able to check for individual features this also
adds a way to query all the features currently available via
cogl_foreach_feature() which will call a callback for each feature.
Since the new functions take an explicit context pointer there is also
no longer any ambiguity over when users can first start to query
features.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds support for multisample based rendering of onscreen windows
whereby multiple point samples per pixel can be requested and if the
hardware supports that it results in reduced aliasing (especially
considering the jagged edges of polygons)
Reviewed-by: Neil Roberts <neil@linux.intel.com>
When creating new onscreen framebuffers we need to take the
configuration in cogl terms and translate that into a configuration
applicable to any given winsys, e.g. an EGLConfig or a GLXFBConfig
or a PIXELFORMATDESCRIPTOR.
Also when we first create a context we typically have to do a very
similar thing because most OpenGL winsys APIs also associate a
framebuffer config with the context and all future configs need to be
compatible with that.
This patch introduces an internal CoglFramebufferConfig to wrap up some
of the configuration parameters that are common to CoglOnscreenTemplate
and to CoglFramebuffer so we aim to re-use code when dealing with the
above two problems.
This patch also aims to rework the winsys code so it can be more
naturally extended as we start adding more configureability to how
onscreen framebuffers are created.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Previously the EGL backend was directly prodding the width/height
members of the framebuffer structure when a configure notify event is
received. However this doesn't set the dirty flag for the viewport so
Cogl will continue using the wrong viewport y offset. The GLX backend
is already using an abstraction for updating the size which does set
the flag. This patch just makes the EGL backend also use that
abstraction.
If we failed to create a native texture from pixmap via EGL or GLX then
we shouldn't call the winsys's texture_pixmap_x11_damage_notify
function. By doing the validation in cogl-texture-pixmap-x11.c the
winsys code can continue to assume that it doesn't need to verify there
is a valid tex_pixmap->winsys pointer.
Thanks to Damien Leone <dleone@nvidia.com> for catching this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=660184
The previous detection was based on color depth only to determine the
texture format to use in GLX. If that worked fine at depths 24 (RGB8)
and 32 (ARGB8), that would fail at depth 30 (BGR10) and fallback to
software instead of using the TFP extension.
This commit uses an efficient population count implementation to
compare the number of 1-bits in color masks against the color depth
requested by the X client. If they are not equal this means that an
alpha channel has been requested.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
As part of the on going, incremental effort to purge the non type safe
CoglHandle type from the Cogl API this patch tackles most of the
CoglHandle uses relating to textures.
We'd postponed making this change for quite a while because we wanted to
have a clearer understanding of how we wanted to evolve the texture APIs
towards Cogl 2.0 before exposing type safety here which would be
difficult to change later since it would imply breaking APIs.
The basic idea that we are steering towards now is that CoglTexture
can be considered to be the most primitive interface we have for any
object representing a texture. The texture interface would provide
roughly these methods:
cogl_texture_get_width
cogl_texture_get_height
cogl_texture_can_repeat
cogl_texture_can_mipmap
cogl_texture_generate_mipmap;
cogl_texture_get_format
cogl_texture_set_region
cogl_texture_get_region
Besides the texture interface we will then start to expose types
corresponding to specific texture types: CoglTexture2D,
CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and
CoglTexturePixmapX11.
We will then also expose an interface for the high-level texture types
we have (such as CoglTexture2DSlice, CoglSubTexture and
CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an
additional interface that lets you iterate a virtual region of a meta
texture and get mappings of primitive textures to sub-regions of that
virtual region. Internally we already have this kind of abstraction for
dealing with sliced texture, sub-textures and atlas textures in a
consistent way, so this will just make that abstraction public. The aim
here is to clarify that there is a difference between primitive textures
(CoglTexture2D/3D) and some of the other high-level textures, and also
enable developers to implement primitives that can support meta textures
since they can only be used with the cogl_rectangle API currently.
The thing that's not so clean-cut with this are the texture constructors
we have currently; such as cogl_texture_new_from_file which no longer
make sense when CoglTexture is considered to be an interface. These
will basically just become convenient factory functions and it's just a
bit unusual that they are within the cogl_texture namespace. It's worth
noting here that all the texture type APIs will also have their own type
specific constructors so these functions will only be used for the
convenience of being able to create a texture without really wanting to
know the details of what type of texture you need. Longer term for 2.0
we may come up with replacement names for these factory functions or the
other thing we are considering is designing some asynchronous factory
functions instead since it's so often detrimental to application
performance to be blocked waiting for a texture to be uploaded to the
GPU.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This patch basically restores the logic from 1.6. There we assumed that
glXCopySubBuffer won't tear and thus only needs to be throttled to the
framerate, while glBlitFramebuffer needs to always wait to avoid
tearing.
With Nvidia drivers specifically we have seen that glBlitFramebuffer is
not synchronized. Eventually the plan is that Cogl will actually take
into consideration the underlying driver/hw vendor and driver version
and we may want to only mark glBlitFramebuffer un-synchronized on
Nvidia.
https://bugzilla.gnome.org/show_bug.cgi?id=659360
Reviewed-by: Robert Bragg <robert@linux.intel.com>
