664077 - createLinearGradient not displaying

Status: RESOLVED INACTIVE

(Core :: Graphics: Canvas2D, defect)

Description

[Shaon Barman]

Attachment: example of gradient not showing

In test.html, the call to fillRect does not properly display the gradient. If the fillStyle is changed to a single color, then the rectangle is shown.

In the commented section, the same rectangle is rendered correctly. The only difference between that section and the original is that context is scaled differently.

Comment 1

[Andreas Gal :gal]

++shaon

Comment 2

[Andreas Gal :gal]

This is biting Shaon's intern project pretty bad. I am offering a large quantity of a beverage of their choice to the person who could whip up a quick fix for us.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

WFM on Windows (D2D). Presumably a cairo/X bug? Possibly even a pixman bug.

Comment 4

[Andreas Gal :gal]

Works on macosx. I guess we can work around this by giving shaon a different machine. That makes this a lot less urgent. Thanks!

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You should check any of the _cairo_fixed_16_16_from_double calls in _cairo_xlib_surface_acquire_pattern_surface are failing due to out-of-range.

Try setting MOZ_CANVAS_IMAGE_SURFACE in your environment (see nsCanvasRenderingContext2D::SetDimensions) to see if that works around the problem.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Thanks for filing this, Shaon!

Doesn't work for me on d2d.  I found while hacking on a similar test that it worked up to scale=499 and abruptly stopped at scale=500, even after varying the other scale-dependent params.  Bas seemed to have an idea (guessed d2d) but we didn't connect on IRC in time.

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Correction!  I had GPU rendering force-disabled to test something else and forgot.  No d2d.

With force-disabled turned off, ... I'm now getting d3d9 instead of d3d10 :|.  So still broken.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Bug definitely lies somewhere within cairo/pixman.  Buggy with d2d and MOZ_CANVAS_IMAGE_SURFACE=1.  Didn't track it down tonight, can poke later if no one beats me to it.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

pixman is bailing out of the stack below because a transformed point is underflowing at this check

	quo = v[j] / (v[2] >> 16);
	if (quo > pixman_max_fixed_48_16 || quo < pixman_min_fixed_48_16)
	    return FALSE;

v[j] = -48947593920512
v[2] = 1073741824
quo  = -2987524043

	xul.dll!_moz_pixman_transform_point(const pixman_transform * transform=0x134b0738, pixman_vector * vector=0x00229cf8)  Line 110	C
 	xul.dll!compute_sample_extents(pixman_transform * transform=0x134b0738, pixman_box32 * extents=0x00229d74, int x=28, int y=360, int x_off=0, int y_off=0, int width=0, int height=0)  Line 607 + 0xd bytes	C
 	xul.dll!analyze_extent(pixman_image * image=0x134b05f0, int x=28, int y=360, const pixman_box32 * extents=0x00229dcc, unsigned int * flags=0x00229db8)  Line 770 + 0x25 bytes	C
 	xul.dll!_moz_pixman_image_composite32(pixman_op_t op=PIXMAN_OP_OVER, pixman_image * src=0x134b05f0, pixman_image * mask=0x00000000, pixman_image * dest=0x136ea490, int src_x=57, int src_y=59, int mask_x=85, int mask_y=419, int dest_x=85, int dest_y=419, int width=250, int height=100)  Line 861 + 0x1f bytes	C
 	xul.dll!_composite_boxes(_cairo_image_surface * dst=0x179d1810, _cairo_operator op=CAIRO_OPERATOR_OVER, const _cairo_pattern * pattern=0x0022aa98, _cairo_boxes_t * boxes=0x0022a55c, _cairo_antialias antialias=CAIRO_ANTIALIAS_DEFAULT, _cairo_clip * clip=0x00000000, const _cairo_composite_rectangles * extents=0x0022a79c)  Line 3007 + 0x4d bytes	C
 	xul.dll!_clip_and_composite_boxes(_cairo_image_surface * dst=0x179d1810, _cairo_operator op=CAIRO_OPERATOR_OVER, const _cairo_pattern * src=0x0022aa98, _cairo_boxes_t * boxes=0x0022a55c, _cairo_antialias antialias=CAIRO_ANTIALIAS_DEFAULT, _cairo_composite_rectangles * extents=0x0022a79c, _cairo_clip * clip=0x00000000)  Line 3041 + 0x21 bytes	C
 	xul.dll!_cairo_image_surface_fill(void * abstract_surface=0x179d1810, _cairo_operator op=CAIRO_OPERATOR_OVER, const _cairo_pattern * source=0x0022aa98, _cairo_path_fixed * path=0x565788ac, _cairo_fill_rule fill_rule=CAIRO_FILL_RULE_WINDING, double tolerance=0.10000000000000001, _cairo_antialias antialias=CAIRO_ANTIALIAS_DEFAULT, _cairo_clip * clip=0x00000000)  Line 3761 + 0x27 bytes	C
 	xul.dll!_cairo_surface_fill(_cairo_surface * surface=0x179d1810, _cairo_operator op=CAIRO_OPERATOR_OVER, const _cairo_pattern * source=0x0022aa98, _cairo_path_fixed * path=0x565788ac, _cairo_fill_rule fill_rule=CAIRO_FILL_RULE_WINDING, double tolerance=0.10000000000000001, _cairo_antialias antialias=CAIRO_ANTIALIAS_DEFAULT, _cairo_clip * clip=0x00000000)  Line 2341 + 0x2f bytes	C
 	xul.dll!_cairo_gstate_fill(_cairo_gstate * gstate=0x565785f8, _cairo_path_fixed * path=0x565788ac)  Line 1295 + 0x52 bytes	C
 	xul.dll!_moz_cairo_fill_preserve(_cairo * cr=0x565785d8)  Line 2459 + 0x16 bytes	C
 	xul.dll!gfxContext::Fill()  Line 151 + 0xc bytes	C++
 	xul.dll!nsCanvasRenderingContext2D::DrawPath(nsCanvasRenderingContext2D::Style style=STYLE_FILL, gfxRect * dirtyRect=0x0022ad3c)  Line 1962	C++
 	xul.dll!nsCanvasRenderingContext2D::DrawRect(const gfxRect & rect={...}, nsCanvasRenderingContext2D::Style style=STYLE_FILL)  Line 2021 + 0x10 bytes	C++
 	xul.dll!nsCanvasRenderingContext2D::FillRect(float x=3000.0000, float y=20000.000, float w=25000.000, float h=10000.000)  Line 2032	C++
 	xul.dll!nsIDOMCanvasRenderingContext2D_FillRect(JSContext * cx=0x12ac2e90, unsigned int argc=4, jsval_layout * vp=0x0cac00e8)  Line 2284 + 0x2d bytes	C++
 	mozjs.dll!js::CallJSNative(JSContext * cx=0x12ac2e90, int (JSContext *, unsigned int, js::Value *)* native=0x549a8310, unsigned int argc=4, js::Value * vp=0x0cac00e8)  Line 277 + 0xf bytes	C++


Thoughts?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't know pixman. It's probably hard to avoid this kind of problem given pixman's (and cairo's) fixed-point design. Probably somewhere we can normalize the gradient scale to avoid this.

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I stepped through some cairo code that seemed to be trying to do that.  "Real bug" might be there.

Comment 12

[Paul Adenot (:padenot)]

FWIW, I found this comment while searching a cause for this bug : 
http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-pattern.c?mark=1380-1383#1380

Comment 13

[arno renevier]

I debugged a bit and it looks like the overflows does not occur because of createLinearGradient arguments, but instead, because of the transform arguments:

0,010000 0,000000 0,000000 -0,010000 55,000000 719,000000

gives and invert matrix of 

100,000002 0,000000 0,000000 -100,000002 -5500,000123 71900,001607

and

71900,001607 is too large for cairo (_cairo_fixed_16_16_from_double(71900,001607)) returns a negative value.

Then, after ctx.transform (and therefore, cairo_transform) call, gstate->ctm_inverse is wrong in cairo.

Comment 15

[Yury Delendik (:yury)]

Also duplicates
https://github.com/mozilla/pdf.js/issues/15
https://github.com/mozilla/pdf.js/issues/4499

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:lsalzman, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.