This should help clarify the documentation by not mentioning non-existent
devices and prevent any assumed coupling between surface-type values and
devices.
The cairo-freelist-private.h header has a number of static inline
functions which call hidden functions in libcairo. This poses
a problem on Solaris where the native compiler compiles inline
functions whether they are used or not, thereby adding the
link time requirements on hidden functions from whatever code
that includes cairo-freelist-private.h. Unfortunately the
boilerplate code includes cairo-private headers and indirectly
the freelist header, so linking the boilerplate helper library
fails on Solaris.
This patch separates the structure definitions from the function
prototypes and static inlines in cairo-freelist-private.h by moving
the datatypes to a new cairo-freelist-type-private.h.
A stray backslash bwetween two assignment lines apparently
invokes a GNU make extension for conditional assignments.
This patch fixes the build when using the native Solaris make.
The exact semantics of the device API can't be spelled out
out in the device API docs since the effects are so tied
to the specific backend. To use a particular device in
practice the user should refer to the backend docs.
The code is passing in the extra info received from
the target surface's acquire_source() method to
_cairo_surface_get_extents() rather than the acquired
source surface itself.
Whenever subsurface extents are not contained in the target extents,
using the source image given by the target (with origin corrected by
using an appropriate offset in the data pointer) is not a valid
operation. Fallback to cloning in that case.
Do not try to hide being a subsurface.
This would cause confusion when users where calling surface-type
specific getters on subsurfaces.
FIXME: We still need public API to access a subsurface's target though.
We initialise the context to a non-error state upon creation, but after
destroy there is a window of opportunity where the object is kept alive
inside the context pool and the user could mistakenly keep on passing
the zombie context into cairo functions. As all entry points need to
check error status, flagging the context as an error object upon the
final unreference prevents such misuse (until such as time as the
context is reallocated).
Make linear-gradient-large ref image match xlib gradients (both on nvidia
and on macosx) and pixman gradients (when patched to compute the linear
gradients using floating point math).
Insertion sort can take up to O(n^2), mergesort is guaranteed to run
in O(n*log(n)).
An example showing bad performance for insertion sort is:
https://bugs.freedesktop.org/show_bug.cgi?id=28067
The mergesort has been engineered to be fast even when working on
cases where the insertion sort would have performed well and as
expected it shows no changes in the benchmark cairo traces.
Vertical RGB mapping previously forced opaque pixels.
To be consistent with horizontal RGB/BGR and vertical BGR it
should use an alpha equal to the mid channel (green).
Add NONPKGCONFIG_EXTRA_LIBS that are only put into the generated pc file
but not used when linking. This is now used to add -lcairo-gobject to
the cairo-gobject.pc file.
Make the loops count depend on the actual calibration_loops/calibration_time
instead of calibration_loops/calibration_max_time.
This avoids having some tests take much less/more than the wanted time per iteration
(I was having some tests taking about 1 second, other taking about 7 seconds when
the ms_per_iteration was 2000)
Spend 0.5-1 times the time wanted for each iteration in calibration, increase the
accuracy of loops count. Just making the loops count be the correct ratio doesn't
guarantee that the iteration time is accurate. By actually measuring iteration
times until it gets greater than 1/4 of the wanted time, the total sum is bound
to be <= the wanted iteration time and last calibration time is between 1/4 and
1/2 of the wanted time, so it should give a very accurate loop count.
The bounds checks on the rectangle to blit were done
after converting target/source to inclusive/noninclusive
coordinates rather than before, potentially causing an
off-by-one in the sizes, since the same logic was applied
to both inclusive and non-inclusive coordinates. This
patch enforces bounds up front.
Thread "OS/2 surface fixes" on cairo-l:
http://lists.cairographics.org/archives/cairo/2010-July/020343.html
Use a single code path to release the resources acquired
for a surface that's been partially constructed, rather than
have multiple error exits which each release the resources
acquired so far.
Thread "OS/2 surface fixes" on cairo-l:
http://lists.cairographics.org/archives/cairo/2010-July/020343.html
Clarify the documentation for cairo_os2_surface_create()
and cairo_os2_surface_set_hwnd() to note that the ownership
of the presentation space and window respectively
remains with the caller.
Thread "OS/2 surface fixes" on cairo-l:
http://lists.cairographics.org/archives/cairo/2010-July/020343.html
On arithmetic overflow the buffer allocator would attempt
to allocate zero bytes instead of failing the allocation.
Depending on the implementation of the underlying allocator
being proxied, this may result in an allocation of a zero
length buffer, causing all kinds of grief. This patch
causes arithmetic overflows to explicitly fail the allocation.
Thread "OS/2 surface fixes" on cairo-l:
http://lists.cairographics.org/archives/cairo/2010-July/020343.html
There's a format mismatch between cairo's pixel formats
and OS/2 24 bpp data: the individual pixels in OS/2 take
only three bytes per pixel, but there needs to be padding
between lines to make the start of a line always be aligned
at a DWORD boundary.
This patch fixes the format conversion code to include
the required padding between rows.
Thread "OS/2 surface fixes" on cairo-l:
http://lists.cairographics.org/archives/cairo/2010-July/020343.html
