| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Commit 38fbe621 added use of the ptrdiff_t type in a header file,
however `make distcheck` complains:
In file included from headers-standalone-tmp.c:1:0:
../../../src/cairo-image-surface-private.h:74:5: error: unknown type name ‘ptrdiff_t’
ptrdiff_t stride;
^
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Image data is often accessed using:
image->data + y * image->stride
On 64-bit achitectures if the image data is > 4GB, this computation
will overflow since both y and stride are 32-bit types.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98165
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
|
| |
|
|
|
|
|
|
|
| |
The GL backend would like to extract a rectangle from another surface
and convert it to a different pixel format. The
_cairo_image_surface_create_from_image() does that by returning a new
image that has the contents of the specified rectangle in the source
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
| |
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
| |
Removes an another undeclared PLT entry and prevents mixing of user_data
with internal state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
| |
This makes it easier to check that the funciton is returning the
correct type of surfaces.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cairo backends often need to map/unmap to a raster surface but they
don't care about the pixel format, as Pixman will be doing the format
handling.
Cairo users cannot know how to access the raw data if the format is
invalid.
The two different scenarios call for different guarantees on the
returned surface.
The private map/unmap functions also makes it possible to simply
return the status upon unmapping.
|
| |
|
|
|
| |
References: https://bugs.freedesktop.org/show_bug.cgi?id=48577
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
| |
As we return the child image to the user and so perform the reference
tracking on it and not the parent win32 display surface, we need to add
a call to destroy the parent from the image surface. This of course
complicates the normal scenario of destroying the parent first, and so
in that case we need to unhook the image->parent before freeing the
surface->image.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
|
| |
Try and undo all the damage that has acrued over the years by plugging
into the compositor pipeline.
References: https://bugs.freedesktop.org/show_bug.cgi?id=42739
References: https://bugs.freedesktop.org/show_bug.cgi?id=42821
References: https://bugs.freedesktop.org/show_bug.cgi?id=33081
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
| |
Rewrite the directfb backend as nothing more than a simpler image
compositor onto a shadowfb that is flushed back to the dfb surface as
required. Future refinements would be to add damage tracking, and to mix
the useful directfb operations (such as solid fills and alpha blends).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
| |
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new GPU accelerated backend for Cairo based on the Cogl 3D
graphics API.
This backend aims to support Cairo in a way that translates as naturally
as possible to using a GPU, it does not strive to compete with the
anti-aliasing quality of the image backend if it can't be done
efficiently using the GPU - raw performance isn't the only metric of
concern, so is power usage.
As an overview of how the backend works:
- fills are handled by tessellating paths into triangles
- the backend has an extra fill_rectangle drawing operation so we have
a fast-path for drawing rectangles which are so common.
- strokes are also tessellated into triangles.
- stroke and fill tessellations are cached to avoid the cpu overhead
of tessellation and cost of upload given that its common for apps to
re-draw the same path multiple times. The tessellations can survive
translations and rotations increasing the probability that they can be
re-used.
- sources and masks are handled using multi-texturing.
- clipping is handled with a scissor and the stencil buffer which
we're careful to only update when they really change.
- linear gradients are rendered to a 1d texture using a triangle
strip + interpolating color attributes. All cairo extend modes
are handled by corresponding texture sampler wrap modes without
needing programmable fragment processing.
- antialiasing should be handled using Cogl's multisampling API
XXX: This is a work in progress!!
TODO:
- handle at least basic radial gradients (No need to handle full
pdf semantics, since css, svg and canvas only allow radial gradients
defined as one circle + a point that must lie within the first
circle.) - currently we fall back to pixman for radial gradients.
- support glyph rendering with a decent glyph cache design. The
current plan is a per scaled-font growable cache texture + a
scratch cache for one-shot/short-lived glyphs.
- decide how to handle npot textures when lacking hardware support.
Current plan is to add a transparent border to npot textures and use
CLAMP_TO_EDGE for the default EXTEND_NONE semantics. For anything else
we can allocate a shadow npot texture and scale the original to fit
that so we can map extend modes to texture sampler modes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. :)
|
|
|
It was supposed to be the centre point of e849e7c92, but I had a little
battle with git and lost...
Reported-by: James Cloos <cloos@jhcloos.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
