s/CAIRO_GOBJECT_TYPE_HNT_METRICS/CAIRO_GOBJECT_TYPE_HINT_METRICS/
However, as we have already released the broken headers, we need to
preserve that mistake in case applications are already using. Since it
is just a #define, there is little associated cost with carrying both
the incorrect spelling and the corrected define.
The existing API only described the method to be used for performing
rasterisation and unlike other API provided no opportunity for the user
to give a hint as to how to trade off performance against speed. So in
order to no be overly prescriptive, we extend the NONE/GRAY/SUBPIXEL
methods with FAST/GOOD/BEST hints and leave the backend to decide how
best to achieve those goals.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add the mesh pattern type and an error status to be used to report an
incorrect construction of the pattern.
Update the backends to make them ready to handle the new pattern type,
even if it cannot be created yet.
This should help clarify the documentation by not mentioning non-existent
devices and prevent any assumed coupling between surface-type values and
devices.
