The glReadBuffer/glDrawBuffer functions are not present in GLES2, only
a single buffer is supported.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The default support for GLES2 NPOT textures is very limited. We need the
additional features provided by the GL_OES_texture_npot extension.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The previous used value, GL_MAX_TEXTURE_UNITS, is only appropriate for the
fixed pipeline. It is replaced with GL_MAX_TEXTURE_IMAGE_UNITS that refers to
the number of texture units available in the fragment shader.
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>
GLES2 doesn't support Pixel Buffer Objects. Use conventional texture upload
for GLES2 (using client-side memory).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
1D textures are not available in GLES2. We use 2D textures with height 1
instead, which are equivalent to 1D textures and exist across all GL flavors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The GL_CLAMP_TO_BORDER wrapping method (used with CAIRO_EXTEND_NONE) is not
available in GLES2. We use shaders to implement similar functionality for
GLES2.
If bilinear filtering is used, the shader performs a linear fade to
transparency effect in the texel coordinate intervals [-1/2n, 1/2n]
and [1 - 1/2n, 1 + 1/2n] (n: texture size).
If nearest filtering is used, the shader ensures that a clear color is
used for all texel coordinate values outside [0, 1).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This makes the shader emitter functions more versatile. It allows them to use
all information provided by the operands and the context to decide what shader
to produce.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The GL version string returned by glGetString() for GLES doesn't have the
version number at the beginning of the string.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Søren Sandmann Pedersen spotted that we had reversed the channel order
in the conversion back from the pixman format codes to
CAIRO_FORMAT_RGB30.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a common format used by framebuffers to drive 10bpc displays
and is often hardware accelerated by XRender with underlying support
from pixman's x2r10g10b10 format (which provides coercion paths for
fallbacks).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The check-doc-syntax step of 'make check' reports:
./cairo-gl.h: * cairo_device_t, which represents an GL context created by the user.
Error: some function names in the docs are not followed by parentheses.
Fix this by searching for the following regexp in the above files:
'^[^:]*:[/ ][*]\(\|[ ].*\)\([^#']\|^\)\<\(cairo_[][<>/0-9a-z_]*\>[^][<>(]\)'
gcc complains that
cairo-surface-wrapper.c:647: warning: ignoring return value of
‘_cairo_rectangle_intersect’, declared with attribute warn_unused_result
It can be silenced by making _cairo_rectangle_intersect()
cairo_private_no_warn. This makes it possible to avoid unused
temporary variables in other places and reduces the dead assignments
reported by clang static analyzer from 114 to 98.
gcc does not know thta num_glyph is guaranteed to be strictly
positive, so it complains that:
cairo-image-surface.c:3787: warning: ‘status’ may be used uninitialized in this function
Unify the _cairo_rectangle_list_create_in_error() functions, keeping
the best features from both (the one in cairo-clip.c statically
allocates the most common cases, the one in cairo.c throws a NO_MEMORY
error when it cannot malloc() instead of rethrowing the same error).
The same function can be used to return an error-list in
_cairo_gstate_copy_clip_rectangle_list() when _cairo_clip_rectangle()
fails (for example becaouse of an OOM).
cairo_set_font_size() should be equivalent to setting the font matrix
to an appropriate scale matrix.
Implementing it this way saves some code and makes sure that the same
code path is used whenever the font matrix is changed.
3-sided boxes can be replaced with rectangles when clipping and
filling, but not when stroking. _emit_path() is used for all of these
operations, so it cannot perform the optimization except for 4-sided
boxes.
Fixes stroke-open-box.
__cairo_path_fixed_is_rectangle() is used by the PS and PDF backends
to check if a path is equivalent to a rectangle when stroking. This is
different from being a rectangle when filling, because of the implicit
close_path appended to every subpath when filling.
Fixes stroke-open-box.
See https://bugs.freedesktop.org/show_bug.cgi?id=34560
The RENDER specification requires radial gradients to have the first
circle completely inside the second one, but the error is not actually
generated.
The implementation produces the expected results if either circle
contains the other one, so only fall back in these cases.
The RENDER specification does not specify the constraints on the
gradient stops, but its implementation returns an error if less than 2
stops are used.
Xlib and XCB can work around this because gradients with just one stop
are by-definition the same as gradients with that stop repeated twice.
Fixes radial-gradient-one-stop.
All cairo_xcb_picture_t now get their own, private Picture instead of possibly
sharing it with a cairo_xcb_surface_t.
This solves a cyclic dependency which caused cairo_xcb_picture_t to be leaked
until their device was finished.
When an xcb surface was used as a source, a cairo_xcb_picture_t was created
which kept a reference to the surface. This picture was then added as a snapshot
to the surface which caused the surface to own a reference to the picture.
As a result, the Picture and possibly its associated Pixmap were not freed on
the X11 server which could thus run out of memory.
This change causes more Pictures to be created which could possibly slow down
cairo-xcb. There seems to be no measurable difference with cairo-perf-trace. For
the micro benchmarks, this has the most impact on paint_similar-rgba_source.512:
min(ticks) min(ms) median(ms) stddev. iterations overhead
before 158732 0.159 0.159 0.11% 4: 1651.49
after 162579 0.163 0.163 0.18% 4: 1612.41
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=34912
Signed-off-by: Uli Schlachter <psychon@znc.in>
This flag was only ever tested, but never set. Also, there is no X11 server out
there which actually supports this.
AFAIK it was just an experiment which turned into dead code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
RENDER 0.11 added PDF operators and the cairo-xcb backend is already prepared
for handling them. However, it doesn't actually handle them.
If you used such an operator with RENDER 0.11, _operator_is_supported() would
return TRUE, but later on an ASSERT_NOT_REACHED in _render_operator() is hit.
Signed-off-by: Uli Schlachter <psychon@znc.in>
