Fixes the following compiler warning:
cairo-gl-surface.c:182:5: warning: enumeration value
‘PIXMAN_a8r8g8b8_sRGB’ not handled in switch
Same fix as done for image in 1d0055078.
Chris Wilson <chris@chris-wilson.co.uk>
When creating a texture surface that is larger than the maximum
framebuffer or texture dimensions of the context, return a surface in
error. Previously the code failed an assertion, but this prevents an
application from easily detecting when to fall back.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Disentangle the action of binding the framebuffer from setting the
destination. This straightens up the code a bit and avoids some redundant
operations (such as reacquiring the context) when simply switching from
the multi-sample framebuffer to the single-sample framebuffer and vice
versa.
When flushing a surface, we must resolve multisampling for desktop GL.
This allows use of the original surface texture in any following raw GL
operations. This fixes accelerated canvas with WebKitGTK+ using the MSAA
compositor.
In normal cases, we want to flush pending operations reading from the
texture before modifying its contents. However during uploading of
glyphs into the glyph cache, we repeatedly modify the texture as we
construct the vbo (whilst referencing it for that operation). We track
unused areas in the glyph cache so that if we run out of space, we can
explicitly flush the pending glyphs and start afresh and avoid having to
flush the operation in common case.
When clearing a GL surface, set is_clear to true, and when mapping to an
image, handle is_clear like surfaces without modification. Additionally,
explicitly clear surfaces created via cairo_surface_create_similar.
In order to overload the emitters in future to provide specialised
routines for the common types of operands, begin by switching the
current users over to a vfunc interface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Some OpenGLES2 drivers support downloading BGRA data. On little-endian
systems BGRA and GL_UNSIGNED_BYTe is equivalent to the typical
cairo_image_t format, so this can prevent CPU bit swizzling for
operations that involve images.
Instead of allocating a depth/stencil buffer for all surfaces, share a
common buffer that's the size of the largest surface. This reduces
video memory usage when there are many GL surfaces.
In _cairo_gl_surface_map_to_image(), the image surface data has been
filled by glReadPixels, so is_clear flag should be set to FALSE.
Otherwise mapped image surface does not get drawn as it is presumed
clear and so returns true from nothing_to_do().
This implementation is not very efficient at the moment and does not
work with platforms using the incompatible IMG extension (mobile
GPUs). Performance improvements and mobile GPU support will follow.
We need to fix y-axis origin when map a GL surface to image surface for
non-texture GL surface.
Test cases: extended-blend-alpha-mask, extended-blend-mask.
Although the image outputs is not right, but the image on the first grid
(upper-left corner) is correct comparing to image output.
Not 100% improvement, there are still a variety of failures with
GLXWindows, but getting there. At least it fixes more things than its
breaks...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
EGL mandates that the current context be valid for a call to
swapbuffers, and does not just operate upon the drawable passed in. The
current code prevents this as a side effect of calling flush decouples
the current context (so that the state can be clobbered by the
application without impacting upon Cairo). So when we try to swap, EGL
complains.
We can get the desired behaviour by setting the surface upon the
context, thus calling MakeCurrent as necessary, and then flushing any
pending operations before swapping. This has the positive side-effect
of not clobbering our own state unnecessarily.
Reported-by: Pekka Paalanen <ppaalanen@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The operand->texture.surface should be set to right value, not
NULL. Otherwise, when doing _cairo_gl_surface_operand_init(),
the texture.surface in operand struct will also be NULL, which
is incorrect. This fix regression suite in 43 test cases(such
as source-clip) in cairo/test/.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The traps compositor expects to be able to pass either in a surface or a
source to its composite functions, so make it so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adds basic clipping to the OpenGL MSAA compositor via the
depth and stencil buffers. Stenciling and depth bits are
stored in a renderbuffer.
Note that we only attach renderbuffers to surfaces created by ourselves
and not for foreign drawables (e.g. X Windows).
Let there be textures!
Unbreak the setup of surface operands after my lazy convertion to the
new compositor interface. This is still only the first step, but it gets
the essentials up and running again, enough to keep me happy whilst
sitting in the airport.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
This patch has been generated by the following Coccinelle semantic patch:
// Remove useless checks for NULL before freeing
//
// free (NULL) is a no-op, so there is no need to avoid it
@@
expression E;
@@
+ free (E);
+ E = NULL;
- if (unlikely (E != NULL)) {
- free(E);
(
- E = NULL;
|
- E = 0;
)
...
- }
@@
expression E;
@@
+ free (E);
- if (unlikely (E != NULL)) {
- free (E);
- }
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
b132fae5e8 introduced the usage of two
new pixman formats. This requires pixman 0.22, but makes it possible
to fix some TODO's left behind in gl and vg.
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Work around GLES2 limitations in texture pixel formats and options for
pixel packing/unpacking.
Depending on the endianness and the image pixel format, we may need to
manually swap the elements in a pixel group. This is not currently
implemented, but for little-endian architectures the common pixman BGRA
formats don't need a swap.
Due to GL_UNPACK_ROW_LENGTH missing in GLES2 we have to extract the image
data ourselves in some cases, so we can provide it to glTexSubImage2D
using a layout it can understand. We must extract the pixels if:
a. we don't want full-length lines or
b. the row stride cannot be handled by GL itself using a 4 byte
alignment constraint
We use GL_PACK_ALIGNMENT 4 by default because that is the default pixman
alignment value and in some cases it allows us to avoid the manual pixel
extraction. However, when we extract image data manually we use an alignment
of 1.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
