fixing blurred shadows on hairline paths when rendering to XPS device

[junov1, 2012-04-04 16:35:12]

PTAL

[bungeman, 2012-04-04 17:35:40]

On 2012/04/04 16:35:12, junov1 wrote:
> PTAL

It seems like it would be a cleaner and smaller change to just replace

SkPaint::kFill_Style

(on line 1788 of the current file) with 

shaderPaint->getStyle()

Does this solve the issue you're seeing?

I believe the reason the code is the way it currently is is because
SkRasterizer::onRasterize always calls with SkPaint::kFill_Style, as it always
expects a fillable path. This may be a bug.

[junov1, 2012-04-04 18:47:25]

That smaller change you suggest does not fix the problem.
The key is to capture the return value of paint.getFillPath(); 
The bug happens when the line width <= 1: the path does not get converted to a
fillable path because it is expected to be rendered with the hairline method.

[bungeman, 2012-04-04 19:18:19]

On 2012/04/04 18:47:25, junov1 wrote:
> That smaller change you suggest does not fix the problem.
> The key is to capture the return value of paint.getFillPath(); 
> The bug happens when the line width <= 1: the path does not get converted to a
> fillable path because it is expected to be rendered with the hairline method.

I am unable to see how your new 'style' variable can have a different value from
the style on shaderPaint. Do you have a test case that I could look at?

[junov1, 2012-04-04 19:38:50]

Ah, shaderPaint! (not paint)
Gotcha!  Ok, I'll do that.

[junov1, 2012-04-04 19:50:30]

OK, so the latest patch does what you suggested and works just fine. I also
included the test, since you asked about it, but I will be submitting it
separately because I still a have to submit a GPU counterpart to this fix before
going through with the whole rebaseling business.

[bungeman, 2012-04-04 19:58:07]

On 2012/04/04 19:50:30, junov1 wrote:
> OK, so the latest patch does what you suggested and works just fine. I also
> included the test, since you asked about it, but I will be submitting it
> separately because I still a have to submit a GPU counterpart to this fix
before
> going through with the whole rebaseling business.

The change to SkXPSDevice LGTM.

As noted in the file, the reason we currently have XPS turned off for GM is that
it uses generated GUIDs for ids inside the document. As a result we always get
different results. We may need a magic "GM" compile flag and use incremental,
not quite "GUID"s.

[junov1, 2012-04-04 20:08:35]

On 2012/04/04 19:58:07, bungeman wrote:
> On 2012/04/04 19:50:30, junov1 wrote:
> > OK, so the latest patch does what you suggested and works just fine. I also
> > included the test, since you asked about it, but I will be submitting it
> > separately because I still a have to submit a GPU counterpart to this fix
> before
> > going through with the whole rebaseling business.
> 
> The change to SkXPSDevice LGTM.
> 
> As noted in the file, the reason we currently have XPS turned off for GM is
that
> it uses generated GUIDs for ids inside the document. As a result we always get
> different results. We may need a magic "GM" compile flag and use incremental,
> not quite "GUID"s.

Yeah, I just turned it on locally to inspect results manually.

[junov1, 2012-07-16 15:59:26]

fixed with r3606