While I cannot say much about the "compound renderering" in Agg as I know little about it, but the upsampling method that Mike mentioned seems quite robust. Just a quick question, will it affect the rendered quality of AA'ed artists, like texts? What I mean is, drawing texts w/ AA on (in the upsampled canvas) and downsampling the result may give poor quality? But maybe there is a way to adjust how AA is done in the first place.
Maybe what we can try is to upsample only selected artists, similar to rasterization in vector backends or agg_filter. This will likely consume more memory and maybe more CPU, but may give minimal side effects. While it is not directly related to the current issue, I thought it would be good to have, within a backend, multiple layers to render and the final result is a composite of those layers. And we may upsample some layers or apply effects selectively. And do the alpha compositing of layers in the end. This will be also useful for animations as we can only update selected layers. Back to the original issue, I am inclined to play with Mike's upsamping method to see if it solves the problem without significant side effects. Regards, -JJ On Thu, Mar 7, 2013 at 6:54 AM, Michael Droettboom <md...@stsci.edu> wrote: > Thanks for bringing this up -- I was just looking at the test images the > other day and was reminded how filled contouring doesn't look as good as it > could be. > > I had played with the "compound renderer" example in Agg some years ago, > but couldn't really understand how it worked, so ultimately gave up on it. > I appreciate the research you've done here, because it illustrates pretty > clearly what is required. I guess in the actual Agg draw_path_collection > renderer, we would have to build a style_handler table dynamically based on > the collection and then iterate through it as we draw... At least it's > clear now how that could be accomplished. > > I wonder, though, and the SVG article you link to hints at this, if we > wouldn't be better off just upsampling our Agg rendering instead. The > advantage of such an approach would be that the structure or ordering of > the drawing wouldn't matter at all -- allaying most of Eric's concerns. It > seems like it just overall be "easier" to do the right thing. And it > should benefit all things, including other tricky things like quadmeshes, > "automatically". > > Of course, the downside is a performance hit. Assuming 2x oversampling, > it means the screen buffer will be 4x the size, rendering will take "up to" > four times as long, and then you have to downsample again (which in the > best case would happen in hardware). Compound rendering has a memory > penalty, too, of course, since the scanlines for all of the paths have to > be stored until finally rendered out simultaneously. Estimating what that > overhead is much harder, of course, and is more content dependent, whereas > the performance hit upsampling is straightforward and has an obvious upper > bound. > > I put together a very quick hack on my agg-upsampling branch, which > hardcodes the upsampling to 2x in each direction. It currently only works > with the GtkAgg backend (even file saving won't work correctly), and I only > fixed things up for contour plotting, so images (and probably other things) > will be misplaced. But it should give an idea for the performance hit and > quality benefit enough to play around with. > > Mike > > > On 03/06/2013 03:27 PM, Michael Droettboom wrote: > > I'm trying to compile your examples, but it seems perhaps you forget to > include a file -- pixel_formats.hpp? It's not in the agg24 source tree. > > Mike > > On 03/06/2013 12:06 PM, Phil Elson wrote: > > Smart rendering of adjacent, anti-aliased patches is a question which > has come up a couple of times in various guises in the past. > It is my understanding that the lack of this functionality led us to > disable anti-aliasing for contouring and is the reason the following image > has a white stripe around the circle where there should be just a nice > blend of the two colors: > > > import matplotlib.pyplot as plt > import numpy as np > import matplotlib.patches as mpatches > import matplotlib.path as mpath > import matplotlib.collections as mcol > > > # create two paths. One a circle, the other > # a square with the same circle cut out. > x = np.linspace(0, np.pi * 2, 1000) > > circle_coords = np.array(zip(*[np.sin(x) * 0.8, np.cos(x) * 0.8])) > pth_circle = mpath.Path(circle_coords) > > sqr_codes = np.repeat(mpath.Path.MOVETO, len(circle_coords) + 5) > sqr_codes[1:5] = mpath.Path.LINETO > sqr_codes[6:] = mpath.Path.LINETO > sqr_coords = np.concatenate([[[-1, -1], [-1, 1], [1, 1], [1, -1], [-1, > -1]], > circle_coords[::-1]], axis=0) > sqr_path = mpath.Path(sqr_coords, sqr_codes) > > > ax = plt.axes() > patches = [mpatches.PathPatch(pth_circle), mpatches.PathPatch(sqr_path)] > col = mcol.PatchCollection(patches, > antialiaseds=True, > edgecolors='none', > facecolors=[(0, 0.0, 0.0, 0.9), (0.1, 0.1, > 0.02, 0.9)]) > ax.add_collection(col) > ax.set_xlim([-1, 1]) > ax.set_ylim([-1, 1]) > plt.show() > > > > I know of lots of the workarounds for this (turn off AA, turn on lines, > extend the path slightly, set a dark background color) all of which have > down-sides, so I'm keen to find a final solution to the problem. > > When the two patches marry up perfectly with full anti-aliasing, the > antigrain (AGG) community call this "flash" or compound rendering, and this > capability was added to Agg 2.4 (which we already ship with mpl). > > In order to make full use of the compound rendering technique I believe > the drawing pipeline in "_backend_agg.cpp" would need to change, which > could be problematic. A less wide-impacting alternative would be to draw > all "patches" of a single Collection in the same rasterization step (i.e. > just change _draw_path_collection_generic), though this does mean that, as > it stands, the result of plt.contourf would not be able to make use of this > new functionality - a MEP which changes the return type of plt.contourf to > a single Collection might be able to fix that. > > I've put together a simple example similar to this in C++ using agg (no > mpl changes yet), showing the differences in the code needed between the > old technique vs the "new" compound renderer (attached). > > > Ok, so the question to those that have knowledge of the _backend_agg.cpp > code (Mike, Eric, JJ + others?): > > > - Have you already looked at doing this and determined that this is a > non-starter? > - Do you support adding the ability for the agg backend to draw > compound artists (i.e. Collections) in this way rather than treating them > as individual primitives in the canvas? > - Since many of the other backends can't do flash rendering, would we > even want to make this change? > - SVG in Firefox 10.0.2 has the same problem, it is discussed > slightly more in > http://www.svgopen.org/2002/papers/sorotokin__svg_secrets/ > - Acroread has the same problem with PDFs, only to a much lesser > extent than in the PNG attached > > > Thoughts? > > > > > > > > > > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > > > > _______________________________________________ > Matplotlib-devel mailing > listMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > > > > _______________________________________________ > Matplotlib-devel mailing > listMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >
<<image/png>>
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
