[Pixman] Plan to release final development version before stable branch

[Bill Spitzak]

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 <oded.gabbay at gmail.com> wrote:

> On Wed, Dec 16, 2015 at 4:41 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> >
> >
> > On Tue, Dec 15, 2015 at 1:29 AM, Oded Gabbay <oded.gabbay at gmail.com>
> wrote:
> >>
> >> On Sat, Dec 12, 2015 at 9:10 PM, Bill Spitzak <spitzak at gmail.com>
> wrote:
> >> >
> >> >
> >> > On Sat, Dec 12, 2015 at 10:37 AM, Oded Gabbay <oded.gabbay at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Sat, Dec 12, 2015 at 8:34 PM, Bill Spitzak <spitzak at gmail.com>
> >> >> wrote:
> >> >> > On Fri, Dec 11, 2015 at 4:15 AM, Oded Gabbay <
> oded.gabbay at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On Thu, Dec 10, 2015 at 11:19 PM, Bill Spitzak <spitzak at gmail.com
> >
> >> >> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20151221/22cd86ab/attachment.html>