I suspect I will need to check the X server version, actually. That seems to be what the other tests are doing.
My main concern is to figure out *which* version this (will) happen in. I am hoping this can be known before code release so Cairo can be updated to use it at the same time. On Sun, Dec 20, 2015 at 5:58 AM, Oded Gabbay <[email protected]> wrote: > On Wed, Dec 16, 2015 at 4:41 AM, Bill Spitzak <[email protected]> wrote: > > > > > > On Tue, Dec 15, 2015 at 1:29 AM, Oded Gabbay <[email protected]> > wrote: > >> > >> On Sat, Dec 12, 2015 at 9:10 PM, Bill Spitzak <[email protected]> > wrote: > >> > > >> > > >> > On Sat, Dec 12, 2015 at 10:37 AM, Oded Gabbay <[email protected]> > >> > wrote: > >> >> > >> >> On Sat, Dec 12, 2015 at 8:34 PM, Bill Spitzak <[email protected]> > >> >> wrote: > >> >> > On Fri, Dec 11, 2015 at 4:15 AM, Oded Gabbay < > [email protected]> > >> >> > wrote: > >> >> >> > >> >> >> On Thu, Dec 10, 2015 at 11:19 PM, Bill Spitzak <[email protected] > > > >> >> >> wrote: > >> >> >> > Can you include my patches to fix the filtering? They have been > >> >> >> > posted > >> >> >> > for a > >> >> >> > long time now. > >> >> >> > > >> >> >> > The last patch makes GOOD/BEST use filtering for scaling images > >> >> >> > down. > >> >> >> > This > >> >> >> > matches the current Cairo behavior and would allow Cairo to use > >> >> >> > the > >> >> >> > pixman > >> >> >> > backend rather than doing an image fallback for any image > scaling > >> >> >> > smaller > >> >> >> > than .75. It also contains a bunch of minor optimizaion and > filter > >> >> >> > selection > >> >> >> > tweaks that makes the output somewhat better than current Cairo. > >> >> >> > > >> >> >> Hi Bill, > >> >> >> > >> >> >> Unfortunately, I don't see anyone reviewed your patches, and from > >> >> >> what > >> >> >> I heard, those are quite significant changes. > >> >> >> > >> >> >> It's a shame you didn't bring this up when I did the first > >> >> >> development > >> >> >> release 4 months ago. Then we had enough time to check and test > it. > >> >> >> I'm quite hesitant of including such changes right before the > final > >> >> >> development version, even with a review. > >> >> > > >> >> > > >> >> > I did send email on May 22, 2015, in response to your comments. > >> >> > >> >> That's strange, because I only started working on pixman during June > of > >> >> 2015... > >> > > >> > > >> > You are right. That was just a general email I sent trying to get > >> > somebody > >> > to look at the patches. Searching in the history I found 3 of these. > >> > > >> >> > >> >> > >> >> > >> >> > > >> >> >> I suggest that you try to contact one of pixman's veterans (Soren, > >> >> >> Siarhei, Matt, Pekka, Ben) offline and ask them nicely to at least > >> >> >> skim over the patches and give a high-level opinion about the > >> >> >> series. > >> >> > > >> >> > > >> >> > These were discussed with Soren before. He disagreed with my > previous > >> >> > version because I changed to a single filter calculation rather > than > >> >> > his > >> >> > pair of filters being convoluted. This version preserves the pair > of > >> >> > filters, with some fixes of bugs that caused artifacts in the > >> >> > resulting > >> >> > filters. I'm sending email directly in case they are not reading > the > >> >> > pixman > >> >> > list. > >> >> > >> >> Could you send me those emails ? > >> > > >> > > >> > I forwarded the big one from him and my response. The patches I have > had > >> > since then I believe address his concerns and preserve the 2-filter > >> > convolution api, they are just bug fixes and some efficiency changes. > >> >> > >> >> > >> >> >> > >> >> >> > >> >> >> Also, check if you need to rebase the patches against current > pixman > >> >> >> and if so, maybe send the series again. It might stir up a > >> >> >> discussion. > >> >> > > >> >> > > >> >> > The patches applied to the newest version without any conflicts and > >> >> > my > >> >> > test > >> >> > programs still work. I have resent them to the pixman mailing list. > >> >> >> > >> >> > >> >> Great! > >> >> > >> >> >> > >> >> >> I'm willing to review them in terms of correctness and code style, > >> >> >> but > >> >> >> I'm not veteran enough in pixman to give an opinion on the > >> >> >> underlying > >> >> >> changes (which is the most important issue). > >> >> > > >> >> > > >> >> > Anything would be great. > >> >> > > >> >> > I believe these work well and have been using them for a while. > This > >> >> > would > >> >> > allow the removal of redundant code in Cairo, and would allow > 2-pass > >> >> > filtering to be done at some point in the future, which would > really > >> >> > improve > >> >> > pixman performance. > >> >> > > >> >> ok, I'll try to take a look next week or so. > >> >> > >> >> Oded > >> > > >> > > >> > >> Hi Bill, > >> > >> I read most of the emails you sent me and I cleared time tomorrow to > >> review your patches. > >> > >> Having said that, IMHO, I believe it would be too risky to merge them > >> into the final development release. This is due to a combination of > >> two things: > >> > >> A. This release, although it is a "development release" is used by > >> current distributions (fedora 22,23, ubuntu, debian). That's because > >> there was a big gap in the release schedule earlier this year. > >> > >> B. The changes here affect users of pixman and cairo, by changing the > >> way pixman behaves. So even if your patches are perfect, and the > >> result is a better pixman, we need to give time to users (and to > >> cairo) to adapt to it. This can only be done in master branch, not in > >> stable branches. > >> > >> So, what I intend to do is to: > >> > >> A. Review your patches and if necessary, ask you to fix issues. > >> > >> B. Assuming no objection will be made by other pixman developers > >> during the next couple of weeks, I will merge the patch series into > >> master *after* I branch out the 0.34 release. > >> > >> That way, the patch series will be included in the future development > >> releases that will be packaged inside "testing" distributions, such as > >> fedora rawhide and debian unstable, and thus we will have time to > >> receive feedback from users about the changes. > >> > >> I hope this is accepted by you and by everyone else. If not, please tell > >> me. > >> > >> Thanks, > >> > >> Oded > > > > > > I am fine with this all being for the next release and will be happy to > > answer any questions. > > > > I would like to know what a compile-time test for whether libpixman is > this > > next release or not, and a run-time test to see if X (using both xlib and > > xcb) is using this next release of pixman. This will allow code to be > added > > to Cairo to automatically send the filtering to pixman when possible, and > > hopefully get that added at the same time this is supported in the pixman > > release. > > > > > > > > For compile time, you can check PIXMAN_VERSION_MAJOR/MINOR/MICRO in > pixman-version.h > > For run-time, check pixman_version() in pixman.c: > > /** > * pixman_version: > * > * Returns the version of the pixman library encoded in a single > * integer as per %PIXMAN_VERSION_ENCODE. The encoding ensures that > * later versions compare greater than earlier versions. > * > * A run-time comparison to check that pixman's version is greater than > * or equal to version X.Y.Z could be performed as follows: > * > * <informalexample><programlisting> > * if (pixman_version() >= PIXMAN_VERSION_ENCODE(X,Y,Z)) {...} > * </programlisting></informalexample> > * > * See also pixman_version_string() as well as the compile-time > * equivalents %PIXMAN_VERSION and %PIXMAN_VERSION_STRING. > * > * Return value: the encoded version. > **/ > > I don't know, however, if X server exports this function through its > API. You will need to check with them. > > Oded >
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
