Skip to content

polypath winding rule with transparency

4 messages · Paul Murrell, Michael Sumner

#
Hi, I see different results in png() and pdf() for polypath() on Windows
when using the "winding" rule

## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
          c(.1, .6, .6, .1, NA, .4, .9, .9, .4))

pfun <- function() {
  plot(x)
  polypath(x * 0.8 + 0.2,  rule = "winding", col = "#BEBEBE80")
  polypath(x,  rule = "winding", col = "#BEBEBE80")
}

## output  "windows.png/pdf" or "unix.png/pdf"
label <- .Platform$OS.type
png(sprintf("%s.png", label))
pfun()
dev.off()
pdf(sprintf("%s.pdf", label))
pfun()
dev.off()


Visually, the result in the "windows.png" file is as if the "evenodd" rule
was specified. All other examples unix.pdf, unix.png, windows.pdf give me
the expected result - which is "all bounded regions shaded grey, with two
tones for the different regions of overlap". The unexpected result is the
completely transparent region.

Is this a known/expected difference on Windows?  I see the unexpected
result in 3.3.1 and in R version 3.3.1 Patched (2016-07-27 r70991) on
Windows.

Cheers, Mike.
#
Hello,

it's probably worth adding that this is not a problem with pathGrob, only
polypath.

This code is sufficient to demonstrate the problem in Windows.

## overlapping, both clock-wise
x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9),
          c(.1, .6, .6, .1, NA, .4, .9, .9, .4))
## only a problem on Windows windows() and png()
plot(x);polypath(x, rule = "winding", col = "#BEBEBE80")

This code shows the same behaviour on different systems/devices.

## no problem on Windows/Linux/PNG/PDF ...
library(grid)
grid.newpage()
pushViewport(viewport(0.5, 0.5, width = 1, height = 1))
grid.draw(pathGrob(x[,1], x[,2], rule = "winding", gp = gpar(fill =
"#BEBEBE80")))

Cheers, Mike.
On Wed, 3 Aug 2016 at 16:24 Michael Sumner <mdsumner at gmail.com> wrote:

            
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia
#
Hi

Just to clarify, I think this IS a problem with grid.path() as well as 
polypath().

For the example you give, grid.path() diverts to drawing a polygon 
(because there is no 'id' specified), and the NAs in 'x' generate two 
separate polygons, which get drawn one on top of the other.

The correct analogy to the polypath() example is ...

x2 <- matrix(x[!is.na(x)], ncol=2)
grid.path(x2[,1], x2[,2], id=rep(1:2, each=4),
           rule="winding", gp=gpar(="#BEBEBE80"))

... which produces the same (wrong) result as polypath() on Windows.

Also, the grid.path() result for your example is NOT the same as the 
correct result;  we do NOT want a separate shade for the intersecting 
region when the "winding" fill rule is working correctly.  The fill 
should be the same across the union of the square regions (this is what 
Cairo and PDF on Linux produce).

Another data point:  the problem is NOT just a matter of getting the 
rules round the wrong way in the devWindows.c;  using rule="evenodd" 
produces the SAME result as using rule="winding".

One more data point:  this is not JUST a problem with polypath(). 
Creating a self-intersecting polygon and then drawing it, using 
polygon(), in windows(fillEvenOdd=FALSE) and windows(filleEvenOdd=TRUE) 
produces exactly the same result.

Sadly, none of that helps to explain why the "winding" rule is not 
working on Windows :(

Thanks for reporting the problem - needs more study to find out what is 
going wrong.

Paul
On 03/08/16 18:47, Michael Sumner wrote:

  
    
#
On Thu, 4 Aug 2016 at 11:17 Paul Murrell <paul at stat.auckland.ac.nz> wrote:

            
Hi, oh dear - sorry about that

I appreciate the deeper explanation, I knew about the id aspect in grid,
but just forgot in my haste.

I'll be more careful with examples if I find any more clues.

Cheers, Mike.