The Python script is unable to fix all of the warnings, because some
point to comments that are not actually documentation.
Fixes the remaining 'documentation comment not closed with **/'
warnings.
Documentation comments should always start with "/**" and end with
"**/". This is not required by gtk-doc, but it makes the
documentations formatting more consistent and simplifies the checking
of documentation comments.
The following Python script tries to enforce this.
from sys import argv
from sre import search
for filename in argv[1:]:
in_doc = False
lines = open(filename, "r").read().split("\n")
for i in range(len(lines)):
ls = lines[i].strip()
if ls == "/**":
in_doc = True
elif in_doc and ls == "*/":
lines[i] = " **/"
if ls.endswith("*/"):
in_doc = False
out = open(filename, "w")
out.write("\n".join(lines))
out.close()
This fixes most 'documentation comment not closed with **/' warnings
by check-doc-syntax.awk.
The SOURCE and CLEAR are the odd pair in Cairo's range of operators that
are bound by the shape/mask, but are unbound by the source. This
regularly leads to bugs as only track the bound/unbound rectangles and
confuse the meaning when bound only by the mask.
What is required is that the unbound extents in this case is only
trimmed by the mask (the bounded extents are still the intersection of
all).
Fixes bug-source-cu
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
There is need to loop over number of glyphs to check wether the glyph
image is a ARGB32 as the font's antialias option can be used for checking.
If antialias is SUBPIXEL or BEST, the glyph surface will be ARGB32,
otherwise it will be A8 format. Therefore we will only be using
component-alpha at SUBPIXEL (or better) font quality and only then need
a mask for multiple pass glyph composition.
Flushing only releases the fallback if we flush twice with no
intervening damage (the theory is to try and reduce readbacks). So it is
possible for a correctly behaving application to call mark-dirty and there
still be a fallback.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The gradient is relatively small and any differences between upload
methods should be hidden by the caching. As it stands, using pbo with
the gradient fails with fglrx. As the workaround to use a simple
TexImage2D is inconsequential (may even be a minute win) and simplifies
the code, just do it.
A couple of mistakes, such as inverting the logic as to when to flush
damage back from the shadow, meant that nothing happened when drawing to
the directfb surface.
Again still only compile tested.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The damage wasn't being created on the right surface, so the damage to
the fallback image surface was not being tracked. Perform a little bit
of juggling so that we track dirty regions on the fallback surface itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
During the surface flush, we reduce any pending damage and then blit. If
no damage had been accrued then the damage->region would be NULL leading
to a segfault.
Patch suggested by Szuromi Gábor.
Reported-by: Szuromi Gábor <kukkerman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47605
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just emit a marker for when cairo_image_surface_get_data() is called on
a surface so that we have a breadcrumb for when the pixels are first
exported. (Though note that pointer may be kept around and used much
later.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When cairo_surface_create_for_rectangle() is given non-integer parameters,
the subsurface's size may be negative(e.g x = 0.2, width = 0.7, the
final width will be -1). This illegal surface may cause crash somewhere
upon later use, and although the fractional subsurface is ill-defined,
we should never crash!
The extents->clip may be replaced elsewhere and so we cannot assume that
simply because it changed from the stashed value, that it was us that
made that copy. So becareful to only free our copy.
Fixes a double-free of a clip after a complex fallback operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The earliest use of the clip path's polygon fill rule is now for
intersecting the original polygon with the plurality of clip boxes.
However, the initialisation of the fill rule remained after the
intersection.
==8968== Conditional jump or move depends on uninitialised value(s)
==8968== at 0x4C99449: _cairo_polygon_intersect (cairo-polygon-intersect.c:1382)
==8968== by 0x4C9B788: _cairo_polygon_intersect_with_boxes.part.12 (cairo-polygon-intersect.c:1520)
==8968== by 0x4C6AE6E: _cairo_clip_get_polygon (cairo-clip-polygon.c:104)
==8968== by 0x4CAA667: clip_and_composite_boxes.part.13 (cairo-spans-compositor.c:773)
==8968== by 0x4CAAD1D: clip_and_composite_boxes (cairo-spans-compositor.c:758)
==8968== by 0x4CAB25C: _cairo_spans_compositor_fill (cairo-spans-compositor.c:1023)
==8968== by 0x4C6CB69: _cairo_compositor_fill (cairo-compositor.c:184)
==8968== by 0x4C7CE3E: _cairo_image_surface_fill (cairo-image-surface.c:945)
==8968== by 0x4CAE2B6: _cairo_surface_fill (cairo-surface.c:2047)
==8968== by 0x4C74AB7: _cairo_gstate_fill (cairo-gstate.c:1268)
==8968== by 0x4C6E6D3: _cairo_default_context_fill (cairo-default-context.c:1009)
==8968== by 0x4C67944: cairo_fill (cairo.c:2105)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Empty for the moment as there is no need to cross-reference the files in
git against the list in the Makefile anymore, but the release process
still requires it - and it may prove to be useful again in the future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The pen is only used for ensuring that we generate consist vertices
around a fan used for end-capping or line-joining when set to ROUND.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The earlier bug found in edge advancement was actually due to the missed
opportunity of not performing the increment when we know the step is
zero.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
