I was hoping for a bigger win than this, but cairogears is now significantly
faster than it was with just traps. One potential problem is that adding
src texture coordinates blew up vertex size from 12 bytes to 20, and we're
emitting quite a few vertices. There's plenty of hope for the future,
though: With shaders we could remove the 2 new texcoords again by stuffing a
position to source coordinate transformation matrix in constants. Then
with EXT_geometry_shader4 plus EXT_gpu_shader4 we should be able to get the
24 bytes for 2 vertices down to 16 or less.
This is a minor performance regression over software, but is the basis for
not rasterizing the geometry into a temporary mask, which should be a
significant win.
This appears to be no performance difference in cairogears versus the traps
fallback before, but is a step towards handing the information off to the
hardware.
Gl defaults to NEAREST_MIPMAP_LINEAR on new texture objects.
This should save space or bandwidth with DRI drivers, as they'll use the
parameter as a hint, and then not have to either fix up later or waste
space for unused mipmap levels.
This fixes the operator and operator-alpha tests to rgb24 destinations.
While we request an RGB texture, the returned texture has alpha bits, so when
we blend against it as a renderbuffer, we get the junk alpha values. Whether
or not this is a driver bug, we'll have this problem when we get visuals
with alpha bits for windows despite not requestiong alpha, so we have to
handle it in cairo.
This saves the driver from converting the quad into tris on its own. We'd
rather be able to specify a rect as 2-3 points and use the rectangular
rendering feature that most of our hardware has, if it was possible, but
it isn't exposed in GL.
This reverts commit 564d64a132.
In hindsight, and with further discussion with Jeff Muizelaar, this
behaviour of using the stored contents from the mime-data is completely
the opposite of the users' expectations. When the user calls
cairo_surface_write_to_png(), usually in the course of debugging their
rendering code, they expect the precise contents of the surface to be
saved.
At Behdad's request, convert the array of allocators into a simple hash
table (large static number of buckets + chaining) in order to speed up
malloc profiling.
Since we only need to allocate elts for intersection events and edges, the
number of elts in flight at any one time is actually quite small and can
usually be accommodated from an embedded pool.
Propagate the error status from deep within the bowels, in order to reduce
the number of duplicate _cairo_error() and generally clean up the return
values.
We now have the ability to distinguish an error case where the backend is
left in an inconsistent state from a transitory error. For the former we
need to report the error condition via the return value, which will be
propagated to the font-face. For the latter we just construct an in-error
scaled font nil-object which is passed back to the user.
We only want to set the error state on the backend when it implies that
the font-face is in an inconsistent state. For example, this may be due to
a locking error in the backend or that we have detected a corrupt font.
In contrast, if we merely fail to allocated the scaled font then we just
wish to return that error to the user, without making the font-face itself
inert.
Check the user input for validity before passing the values on to the
backend. Currently the error is detected by the backend and the error is
propagated onto the font-face.
Ensure that the temporary images are freed after we finish with the
pattern.
Note that we are using 3 members of the surface for temporary storage
whilst emitting patterns, this should be reviewed.
_cairo_memory_stream_destroy() finalizes the stream even if the stream was
in error and that error is reported back to the caller - so ensure we
don't try to free the stream again.
