| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Cogl's upstream is unmaintained, and has been for the past 6 years.
|
| |
|
|
|
|
|
|
| |
This ensures that if the source surface does not have an alpha
component (such as those with format RGB24), it is not blended
as if it does.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
|
| |
|
|
| |
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
|
| |
|
|
|
|
|
|
|
|
| |
In order to be more consistent with backends such as gl, support for
creating a surface from content, width, and height parameters was
moved into the backend itself. The option to pass cairo-cogl a
framebuffer to create a texture from still exists, just now it is
not the only option.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
|
| |
|
|
|
|
|
|
| |
This makes it so that operators requiring transparent values to be
used outside of the bounds of the source and/or mask textures will
trigger a second rendering of transparent pixels.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
|
| |
|
|
|
|
|
|
| |
With the new cogl API, casting the framebuffer into offscreen
and onscreen types with the provided macros is a deprecated
behavior.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
|
|
|
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.
|
