Integrating new grid features in ggplot2

[thomasp85]

Hi Team

The graphic engine and grid is getting some love lately and we will look into a future where gradient + image fill and non-rectangular clipping is available on the devices that supports it. I think both have interest from the ggplot2 side.

While we are not there yet, @pmur002 has a working implementation and I think we may just as well begin discussing to what extend and how we may use this in ggplot2. I think the most interesting (seeing as ggpattern exist) possibility is gradient fill. This will most definitely be a challenge to integrate into the scale system because gradients depend on multiple values. Should the scaling happen from discrete values to a set of predefined gradients? or should each stop be mapped to different values. Lots of things to discuss!

Non-rectangular clipping also opens up a lot of possibilities, some not having a clear parallel in the current API (e.g. clipping groups or layers to certain areas)

@clauswilke @karawoo @hadley @yutannihilation @paleolimbot please join the discussion 🙂

[paleolimbot]

The geologists are going to be so excited! My quick unqualified comment would be that a vectorized "fill spec" (probably generated by ScalePattern$map()) might do the trick. How that interacts with the colour and fill aesthetics seems tricky.

[clauswilke]

I think allowing fill to vary along x or y in polygons would be very useful, and would probably be something people would expect. As seen here: https://wilkelab.org/ggridges/reference/geom_ridgeline_gradient.html

[pmur002]

If you want to play along, this is all happening in an svn branch [https://svn.r-project.org/R/branches/R-defs/], though that is VERY unstable, both in the sense of being a segfault magnet and in the sense of changing all the time. I am also documenting progress [https://www.stat.auckland.ac.nz/~paul/Reports/r-defs-proposal/defs-proposal.html], though that also needs updating already.

[clauswilke]

Paul, this is great! Do you take feature requests? One feature that would be really useful and probably isn't that much work (famous last words!) is some sort of link or anchor. Obviously it'd have to be ignored in raster devices, but it'd be super useful for svg or pdf output.

[pmur002]

I take requests, but there is no guarantee that I will do anything with them :) I have this semester teaching free (thanks to an R Studio donation to UoA), which is giving me time to tackle something a bit larger like this, BUT I still have to scope it so that I have some hope of getting something merged back to trunk before I sink without trace back into teaching in the next semester. Long way of saying that additional requests are almost certainly out of scope this time around.

[mdsumner]

Thanks @thomasp85 and @pmur002 , could this include (or lead to) general textures, by which I mean any given triangle region could have a fill that is mapped from a bitmap image? Interpolation of the image across the triangle is essentially done at device resolution, with mapping from the triangle corners to the coordinate system of the image. So, I see it as a "fill" across a region that can represent the coordinate system of another data set.

[mdsumner]

(I know it's off-topic, so sorry for jumping on here - been trying to find where to "park" this wish)

[pmur002]

The scope of this project does not include textures. Not sure if textures are ever a real possibility - I am leaving some graphics devices behind with the set of features under consideration, but textures might leave all graphics devices behind :) One outside chance is "mesh patterns" [https://www.cairographics.org/manual/cairo-cairo-pattern-t.html#cairo-pattern-create-mesh], which both Cairo and PDF can in theory support, but that's still not textures.

[clauswilke]

With arbitrary clipping regions, it should be relatively straightforward to implement texture fill by just drawing the texture and then clipping to the desired shape. This can be done outside the graphics device, by client code. (Similar to ggpattern but easier to implement.)

[thomasp85]

I think what @mdsumner is alluring to is to have a each corner of a triangle mapped to a texture location and let every pixel inside the triangle be interpolated from the texture based on these coordinates... I think this would be too hard to solve generally as well - very few 2D drawing libraries support this

[mdsumner]

Great, thanks for the feedback that alone is helpful - appreciate the work here it's exciting, reading @pmur002's document is very enlightening!

[pmur002]

I forgot that my report is on github, so you can keep up with the latest version here (https://github.com/pmur002/r-defs-proposal/blob/master/defs-proposal.html)

[stragu]

Just linking to relevant discussions and prior work:

• Write-up of upcoming changes on R dev blog: https://developer.r-project.org/Blog/public/2020/07/15/new-features-in-the-r-graphics-engine/index.html
• ggpattern package: https://coolbutuseless.github.io/package/ggpattern/index.html
• ggrough package: https://xvrdm.github.io/ggrough/
• patternplot package: https://cran.r-project.org/web/packages/patternplot/vignettes/patternplot-intro.html
• ggtextures package: https://github.com/clauswilke/ggtextures#ggtextures
• StackExchange question on filling areas with patterns/texture: https://stackoverflow.com/questions/2895319/how-to-add-texture-to-fill-colors-in-ggplot2
  • A custom function that came out of one of the answers: https://github.com/cratlagh/EggHatch/