On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen <j...@iki.fi> wrote: > Jae-Joon Lee <lee.j.j...@gmail.com> writes: > >> While extending this to other backend such as pdf and svg should be >> straight forward, I want to hear how others think about the overall >> approach, e.g., api change and such. The current approach is to >> minimize change in backends. > > While the backend API is being changed, would it be similarly easy to > support arbitrary affine transformations? It would make the API more > symmetric, since many other draw_* methods take an affine > transformation, and I guess at least the PS and PDF backends could > easily support this. >
Yes, supporting arbitrary affine transform would not be difficult. On the other hand, I'm not sure if that feature is practically useful, assuming that other rasterizing backend won't implement it. I'll think about it. >> * If there are multiple images (and the ps backend is used), the >> images are resampled as they are compositted into a single image. > > The Figure.draw method already has some logic for not compositing > multiple images: > > if len(self.images)<=1 or not_composite or \ > not allequal([im.origin for im in self.images]): > > I suppose this could also include a check for whether all images have > the same transformation. Anyway, I'm not quite sure what the win from > compositing is for a vector backend. One benefit of compositing would be an indirect support of alpha compositing in the ps backend, although it is not clear this is practically useful. Checking whether compositing is required seems not very straight forward to me. We may try to sort out images that needs to be composited and those does not. Anyhow, I am personally happy with the current behavior so I may leave it as is, and let others take it if they want. > >> * The current solution forces not to resample whenever >> interpolation=="nearest", I think this is generally good behavior. >> However, on the highly extreme case of very high resolution of image >> (e.g., image dpi > 1000 ?), it might be better if the image is >> resampled (i.e., downsampled). > > This sounds like it would make sense for naive users but could get very > annoying for somebody who really does want high resolution (e.g. for > zooming in in a viewer application). What I meant was the case when the dpi of the image painted on the canvas is much higher than the dpi of the canvas itself (I mean the dpi of the typical postscript output device). Anyhow, I guess the current behavior is good enough, and it seems more reasonable to let users do the down-sampling explicitly if they want. Regards, -JJ > > -- > Jouni K. Seppänen > http://www.iki.fi/jks > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
