Menu
▾
▴
Re: [matplotlib-devel] "Flash" rendering in the Agg backend
|
From: Michael D. <md...@st...> - 2013-03-07 14:57:50
|
On 03/06/2013 08:28 PM, Jae-Joon Lee wrote: > 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. In my quick hack, I render the text at the final output resolution, it gets upsampled onto the "larger" canvas, and then downsampled back. (All this just because it was the easiest hack). The end result is definitely fuzzier. So we'd have to explore how we do text rendering in the new paradigm, particularly wrt hinting (which already contains a lot of cleverness). > > 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. That's an interesting idea. > > 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. Yes -- I've thought we might need this for a while. Cairo has a very useful API -- "push_group"/"pop_group" and friends -- that push layers on and off a stack. It would solve some of the alpha blending problems we have because, for example, an entire contour set could be rendered on a single layer and then alpha composited at once on the layer below. Another side effect of that API is that it makes "stamping" things (as we do in draw_marker) possible without each of the backends having to understand so much about what a marker is as we have now. Cheers, Mike > > 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...@st... > <mailto:md...@st...>> 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? >>> o 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/ >>> o 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 list >>> Mat...@li... <mailto:Mat...@li...> >>> https://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 >> Mat...@li... <mailto:Mat...@li...> >> https://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 > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
