[Pixman] [PATCH 02/13] test/check-formats.c: Add support for separable blend modes

From: Søren Sandmann Pedersen s...@redhat.com --- test/check-formats.c | 16 1 file changed, 16 insertions(+) diff --git a/test/check-formats.c b/test/check-formats.c index 7edc198..8eb263b 100644 --- a/test/check-formats.c +++ b/test/check-formats.c @@ -146,6 +146,22 @@ static

[Pixman] [PATCH 05/13] test/tolerance-test: New test program

From: Søren Sandmann Pedersen s...@redhat.com This new test program is similar to test/composite in that it relies on the pixel_checker_t API to do tolerance based verification. But unlike the composite test, which verifies combinations of a fixed set of pixels, this one generates random images

[Pixman] [PATCH 08/13] pixman-combine32.c: Fix bugs related to integer promotion

From: Søren Sandmann Pedersen s...@redhat.com In the component alpha part of the PDF_SEPARABLE_BLEND_MODE macro, the expression ~RED_8 (m) is used. Because RED_8(m) gets promoted to int before ~ is applied, the whole expression typically becomes some negative value rather than (255 - RED_8(m

[Pixman] [PATCH 07/13] pixman/pixman-combine32.c: Bug fixes for separable blend modes

From: Søren Sandmann Pedersen s...@redhat.com This commit fixes four separate bugs: 1. In the computation (1 - sa) * d + (1 - da) * s + sa * da * B(s, d) we were using regular addition for all four channels, but for superluminescent pixels, the addition could overflow causing

[Pixman] [PATCH 11/13] utils.c: Set DEVIATION to 0.0128

From: Søren Sandmann Pedersen s...@redhat.com Consider a HARD_LIGHT operation with the following pixels: - source: 15 (6 bits) - source alpha: 255 (8 bits) - mask alpha: 223 (8 bits) - dest 255 (8 bits) - dest alpha: 0 (8 bits) Since

[Pixman] [PATCH 12/13] Copy the comments from pixman-combine32.c to pixman-combine-float.c

An upcoming commit will delete many of the operators from pixman-combine32.c and rely on the ones in pixman-combine-float.c. The comments about how the operators were derived are still useful though, so copy them into pixman-combine-float.c before the deletion. --- pixman/pixman-combine-float.c |

[Pixman] [PATCH 10/13] Use floating point combiners for all operators that involve divisions

Consider a DISJOINT_ATOP operation with the following pixels: - source: 0xff (8 bits) - source alpha: 0x01 (8 bits) - mask alpha: 0x7b (8 bits) - dest: 0x00 (8 bits) - dest alpha: 0xff (8 bits) When (src IN mask) is computed in 8 bits, the resulting alpha channel is 0 due to

[Pixman] [PATCH 09/13] Soft Light: Consistent approach to division by zero

The Soft Light operator has several branches. One them is decided based on whether 2 * s is less than or equal to 2 * sa. In floating point implementations, when those two values are very close to each other, it may not be completely predictable which branch we hit. This is a problem because in

Re: [Pixman] [PATCH 10/13] Use floating point combiners for all operators that involve divisions

Bill Spitzak spit...@gmail.com writes: - source:0xff (8 bits) - source alpha: 0x01 (8 bits) - mask alpha:0x7b (8 bits) - dest: 0x00 (8 bits) - dest alpha:0xff (8 bits) When (src IN mask) is computed in 8 bits, the resulting alpha channel is 0 due to

Re: [Pixman] Use of uninitialized values (?)

Siarhei Siamashka siarhei.siamas...@gmail.com writes: As a workaround (instead of plugging such holes all over the place), we might allocate the temporary buffers for general path, initialize them once and keep the pointers to these buffers in TLS. However this is not very nice and may hide

[Pixman] [PATCH] configure.ac: Check and use -Wno-unused-local-typedefs GCC option

With GCC 4.8.2 the COMPILE_TIME_ASSERT macro produces a spurious warning about an unused local typedef: In file included from pixman.c:29:0: pixman.c: In function 'optimize_operator': pixman-private.h:1019:22: warning: typedef 'compile_time_assertion' locally defined but not used

[Pixman] Prototype JIT compiler

Hello, Over the Christmas holidays, I spent some time writing a prototype JIT compiler for pixman. Since I may not be able to spend much time working on it in the near future, I thought I'd write up a bit of information about it, in case someone else wants to play around with it. The code is

Re: [Pixman] Prototype JIT compiler

André Tupinambá andre...@gmail.com writes: Long time no see. Indeed -- good to see you back. I just finished my master degree and was thinking about to return my contributions to pixman project, exactly in JIT compiler but with LLVM. What do you think about? Is it a bad idea to create a

Re: [Pixman] [PATCH] test: add a check for FE_DIVBYZERO

Hi, Thanks for the patch. The check +AC_CHECK_DECL([FE_DIVBYZERO], [], [], [[#include fenv.h]]) +if test x$have_fe_divbyzero = xyes; then + AC_DEFINE(HAVE_FEDIVBYZERO, 1, [Whether we have FE_DIVBYZERO]) +fi needs to actually set the $have_fe_divbyzero variable to yes or no. Otherwise

Re: [Pixman] [PATCH v2] test: add a check for FE_DIVBYZERO

Hi, This still doesn't correctly detect that my system has FE_DIVBYZERO, probably because the macro you check for in utils.c is called HAVE_FE_DIVBYZERO, but the one you set in autoconf.c is called HAVE_FEDIVBYZERO (missing an underscore). Since we'll need another revision of this anyway, I

Re: [Pixman] [PATCH v2] test: add a check for FE_DIVBYZERO

Søren Sandmann soren.sandm...@gmail.com writes: we could be consistent with the other checks in autoconf.c and use the ... in configure.ac ..., obviously. Søren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org

Re: [Pixman] pixman-0.26.2 licensing issue

Peter Smith petersmith0...@gmail.com writes: In fact, I would like to find out if the business model we are going to use requires any special conditions of licensing; if it does, it would be great to know from you the details. For the full details, please see the copyright statement of all

Re: [Pixman] [PATCH 0/4] ARMv6 clean-ups and lowlevel-blt-bench fix

Hi, this series was extracted from Ben's last post: http://lists.freedesktop.org/archives/pixman/2013-October/002998.html [PATCH 00/14] Repost of (mostly) ARMv6 patches These 4 are the easy patches, which do not affect performance, but prepare for the following patches to improve

Re: [Pixman] Testing (Re: [PATCH 3/3] ARMv6: Add fast path for over_n_8888_8888_ca)

Siarhei Siamashka siarhei.siamas...@gmail.com writes: - compile pixman with optimizations producing statically linked blitter-test (how?), rename it to blitters-test.armv6 (on rpi) You compile one binary configured as --disable-arm-simd. And another one with arm-simd (armv6) optimizations

[Pixman] [PATCH] create_bits(): Cast the result of height * stride to size_t

In create_bits() both height and stride are ints, so the result is also an int, which will overflow if height or stride are big enough and size_t is bigger than int. This patch simply casts height to size_t to prevent these overflows, which prevents the crash in:

Re: [Pixman] Basic infrastructure for MIPS32r2 and DSPr1 optimizations.

Hi, Some highlevel comments on this patch set: * Most of the patches need more detail in the commit log. Generally, there should be around the level information that someone who is familiar with pixman could write the patch just based on the commit log. It's fine to say just Add

Re: [Pixman] [PATCH 04/11] MIPS: dspr2: runtime detection extended

The commit log here needs to say why and how the runtime detection was extended. See below for more. --- pixman/pixman-mips.c | 83 ++ 1 files changed, 63 insertions(+), 20 deletions(-) diff --git a/pixman/pixman-mips.c

Re: [Pixman] [PATCH 05/11] MIPS: mips32r2: empty implementation with runtime detection

This needs more information in the commit message. See f179263 for an example of the level of information that should ideally be there. Otherwise this patch looks reasonable to me, though as Siarhei noted, it seems a little silly to add all those entirely empty files. But whatever. Søren

Re: [Pixman] [PATCH 07/11] MIPS: dspr1: empty implementation with runtime detection

More information is needed in the commit log. Also, the subject line claims to add an *empty* dspr1 implementation with runtime detection, but the implementation added is not actually empty: it contains blt and fill routines. See the highlevel comments for much more about blt() and fill(), but

Re: [Pixman] Resurrecting: Added fast path for pad type repeats

questions below. On Wed, 13 Feb 2013 08:37:06 +0100 sandmann at cs.au.dk (Søren Sandmann) wrote: I pushed the first patch to master. For this one, did you try comparing Chris' patch to your on ARMv6? Also, did we ever find out whether it was a bug in Firefox. I'm still somewhat skeptical that it's

Re: [Pixman] [PATCH v2] ARM: use pixman_asm_function in internal headers

Hi, I have pushed this one and the two optimizations series to master. Thanks, Søren ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

[Pixman] [PATCH 1/2] test: Add radial-invalid test program

From: Søren Sandmann Pedersen s...@redhat.com This program demonstrates a bug in gradient walker, where some integer overflows cause colors outside the range [0, 255] to be generated, which in turns cause 'invalid' floating point exceptions when those colors are converted to uint8_t. The bug

[Pixman] [PATCH 2/2] pixman-gradient-walker: Make left_x and right_x 64 bit variables

From: Søren Sandmann Pedersen s...@redhat.com The variables left_x, and right_x in gradient_walker_reset() are computed from pos, which is a 64 bit quantity, so to avoid overflows, these variables must be 64 bit as well. Similarly, the left_x and right_x that are stored

[Pixman] [PATCH] test: Rearrange tests in order of increasing runtime

From: Søren Sandmann Pedersen s...@redhat.com Making short tests run first is convenient to catch obvious bugs early. --- test/Makefile.sources | 60 +-- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/test/Makefile.sources b/test

Re: [Pixman] Op. when compositing

Eric Nicolas erik.nico...@gmail.com writes: Hello, I have a question about the OP modes when compositing with Pixman. I had a look at the source code, but this part of the code is quite complex, so I couldn’t find the answer there. What I would like to do is : - Use a plain

Re: [Pixman] Op. when compositing

Eric Nicolas erik.nico...@gmail.com writes: Hello, Thanks for your answer. Below is a small test program (works on little endian machines). As is the result is already strange to me : in: r=20 g=20 b=80 a=FF out: r=90 g=90 b=C0 a=FF Where as I expected the fill color # x

Re: [Pixman] [PATCH 01/13] MIPS: Fix exported symbols in public API.

Nemanja Lukic nemanja.lu...@rt-rk.com writes: --- pixman/pixman-mips-dspr2-asm.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) I have pushed this patch to master and 0.32. Søren ___ Pixman mailing list Pixman@lists.freedesktop.org

[Pixman] [ANNOUNCE] pixman release 0.32.6 now available

.tar.bz2 SHA1: 8791343cbf6d99451f4d08e8209d6ac11bf96df2 pixman-0.32.6.tar.gz SHA1: 5b730399e1e212e5acaa69a4f1a2c7be1af1cdc4 pixman-0.32.6.tar.bz2 GPG signature: http://cairographics.org/releases/pixman-0.32.6.tar.gz.sha1.asc (signed by Søren Sandmann Pedersen

Re: [Pixman] [PATCH pixman] V2 Implement PIXMAN_FILTER_GOOD/BEST as separable filters

Hi, The first patch in this series, which changes the choice of scale for so that it is based on the bounding box of a transformed ellipse, rather than a transformed square makes sense to me. As you say, this makes the filter more invariant under rotations and also less blurry. Also, since the

Re: [Pixman] pixman-0.32.6, Solaris 11.1 amd64

Noel Hunt noel.h...@gmail.com writes: I have just built the above and the clip_test program reports the following: *** BUG *** In _pixman_implementation_lookup_composite: No composite function found The most likely cause of this is that this system has issues with thread local storage

Re: [Pixman] Basic infrastructure for MIPS32r2 and DSPr1 optimizations, and patch for mips* asm exports symbols.

Nemanja Lukic nemanja.lu...@rt-rk.com writes: This patch set should address all previous code review remarks. From looking at this patch set fairly briefly, - There is some confusion about the type of the new memcpy function. Does it return bool or void*? And what precisely does the return

Re: [Pixman] [PATCH 00/32] (Mostly) ARMv6 speedups

Ben Avison bavi...@riscosopen.org writes: No comments at all on the patch series I posted on 2014-08-07? I do have a few tweaks and additions, but rather than sending them all again I'll just repost the changed and new ones: It seems that patch 26/37 is missing, so I can't apply the series

Re: [Pixman] [PATCH 00/32] (Mostly) ARMv6 speedups

Hi, Comments on the patch series below. In the future, please consider sending smaller patch sets so that I can review them in smaller chunks of time. Those are easier to find than multiple consecutive hours ... Thanks, Søren ==

Re: [Pixman] [PATCH] mmx: Use MMX2 intrinsics from xmmintrin.h directly.

On Sun, Oct 25, 2015 at 8:10 PM, Siarhei Siamashka < siarhei.siamas...@gmail.com> wrote: > > Or we could simply do nothing and finally retire MMX support on x86. > If OLPC XO-1 users still do exist, they can always contact us. This is probably the way forward. Except for XO-1, MMX hasn't really

Re: [Pixman] [PATCH] test: Add cover-test

On Wed, Sep 2, 2015 at 7:56 AM, Pekka Paalanen wrote: > Right. I looked at fast_bilinear_cover_iter_init() and > fast_fetch_bilinear_cover() -> fetch_horizontal(), and yes, that really > is how it is implemented. The leftmost pixel is chosen essentially by > n =

Re: [Pixman] [PATCH 1/4] Change conditions for setting FAST_PATH_SAMPLES_COVER_CLIP flags

Ben Avison writes: > For what it's worth, my experience has been that treating the operation > as a two-pass operation (separable into horizontal/vertical passes) > generally outperforms the 2x2 convolution filter approach by a wide > margin. But let's say we still try to

Re: [Pixman] [PATCH 1/4] Change conditions for setting FAST_PATH_SAMPLES_COVER_CLIP flags

Ben Avison writes: > It's an odd omission that it doesn't talk about BILINEAR filtering, > though. However, having briefly read through the text, even though some > of it goes over my head a bit, I'd say it's describing from a strictly > mathematical point of view.

Re: [Pixman] [PATCH] Fix arithmetic overflow in pointer arithmetic in ‘general_composite_rect’

Sure. The extra width check can't harm. Søren On Mon, Sep 21, 2015 at 10:10 PM, Siarhei Siamashka < siarhei.siamas...@gmail.com> wrote: > On Mon, 21 Sep 2015 16:43:46 -0400 > Søren Sandmann <soren.sandm...@gmail.com> wrote: > > > Regardless of who ends up

Re: [Pixman] [PATCH v2] pixman-general: Tighten up calculation of temporary buffer sizes

Pekka Paalanen writes: >> As a discussion point, wouldn't it be better for the ALIGN macro to >> assume 32-byte cache lines? Both 16-byte and 32-byte cachelines are >> currently in common use, but by aligning the buffers to 32-byte addresses >> we would simultaneously

Re: [Pixman] [PATCH] Fix arithmetic overflow in pointer arithmetic in ‘general_composite_rect’

Regardless of who ends up listed as the patch author, this is Reviewed-by: soren.sandm...@gmail.com Søren On Sep 21, 2015 3:07 PM, "Siarhei Siamashka" wrote: > On Mon, 21 Sep 2015 17:10:36 +0200 > l...@gnu.org (Ludovic Courtès) wrote: > > > Hello, > > > > The patch

Re: [Pixman] [PATCH v14 16/22] pixman-filter: distribute normalization error over filter

On Sun, Mar 6, 2016 at 8:06 PM, wrote: > From: Bill Spitzak > > This removes a high-frequency spike in the middle of some filters that is > caused by math errors all being in the same direction. > > Signed-off-by: Bill Spitzak > --- >

Re: [Pixman] [PATCH v14 16/22] pixman-filter: distribute normalization error over filter

On Fri, Mar 18, 2016 at 9:54 PM, Søren Sandmann <soren.sandm...@gmail.com> wrote: > On Sun, Mar 6, 2016 at 8:06 PM, <spit...@gmail.com> wrote: > >> From: Bill Spitzak <spit...@gmail.com> >> >> This removes a high-frequency spike in the middle of some fi

Re: [Pixman] [PATCH 1/2] Add new test of filter reduction from BILINEAR to NEAREST

diff --git a/test/filter-reduction-test.c b/test/filter-reduction-test.c > new file mode 100644 > index 000..72b3142 > --- /dev/null > +++ b/test/filter-reduction-test.c > @@ -0,0 +1,119 @@ > +/* > + * Test program, which can detect some problems with nearest neighbour > + * and bilinear

Re: [Pixman] [PATCH 07/14] pixman-image: Added enable-gnuplot config to view filters in gnuplot

> 1-wide filters - looks triangular, but a 1-wide box would be more >>accurate >> > > Because you are not plotting the two dummy points at (0,±width/2), a > 1-wide filter is actually just a single point. > > You may be right that leaving the dummy points off the plot may make

Re: [Pixman] [PATCH v14 12/22] pixman-filter: fix subsample_bits == 0

On Sat, Apr 9, 2016 at 3:45 PM, Bill Spitzak <spit...@gmail.com> wrote: > On 04/03/2016 11:17 AM, Søren Sandmann wrote: > >> I don't believe this patch is correct. >> >> As an example, consider an image with an identity transformation and a >> cubic filter (wh

Re: [Pixman] [PATCH v14 12/22] pixman-filter: fix subsample_bits == 0

> It does look like there is something really wrong. I compared and (except > for the subsample_bits==0 case) my version produces the same output as the > current git head. > > I think your intention is that there is a sample at offset=0 whether the > filter width is even or odd. However (except

Re: [Pixman] [PATCH v14 12/22] pixman-filter: fix subsample_bits == 0

s a cairo 1.14.x update that uses pixman_filter_create_separate_convolution() instead of the copied-and-pasted filter generator. Other than that, the fix should be straight-forward enough. Søren On Sun, Apr 10, 2016 at 10:01 PM, Søren Sandmann <soren.sandm...@gmail.com> wrote: > > It does look lik

Re: [Pixman] [PATCH v14 05/22] demos/scale: Default to locked axis

Reviewed-by: Soren Sandmann On Sun, Mar 6, 2016 at 8:06 PM, wrote: > From: Bill Spitzak > > Signed-off-by: Bill Spitzak > --- > demos/scale.ui | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [Pixman] [PATCH v14 03/22] demos/scale: Only generate filters when used for separable

> This makes the speed of the demo more accurate, as the filter generation > is a visible fraction of the time it takes to do a transform. This also > prevents the output of unused filters in the gnuplot option in the next > patch. > > Note this is not dependent on other patches, as use can choose

Re: [Pixman] [PATCH v14 16/22] pixman-filter: distribute normalization error over filter

> Also, I would write the code like this: > > pixman_fixed_t error = pixman_fixed_1 - new_total; > for (x = 0; x < width; ++x) > { > pixman_fixed_t d = error * (x + 1) / width; > p[x] += d; > error -= d; > } > > to get rid of the

Re: [Pixman] [PATCH v14 10/22] pixman-filter: Correct integration with impulse filters

On Sun, Mar 6, 2016 at 8:06 PM, wrote: > From: Bill Spitzak > > The IMPULSE special-cases did not sample the center of the of the region. > This > caused it to sample the filters outside their range, and produce assymetric > filters and other errors. Fixing

Re: [Pixman] [PATCH v14 04/22] demos/scale: fix blank subsamples spin box

Reviewed-by: Soren Sandmann On Sun, Mar 6, 2016 at 8:06 PM, wrote: > From: Bill Spitzak > > It now shows the initial value of 4 when the demo is started > > Signed-off-by: Bill Spitzak > --- > demos/scale.ui

Re: [Pixman] [PATCH v13 10/14] pixman-filter: Gaussian fixes

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > The SIGMA term drops out on simplification. > But SIGMA has a meaning here: it's the standard deviation for the normal distribution corresponding to the Gaussian in question, so unless there

Re: [Pixman] [PATCH v13 13/14] pixman-image: Implement PIXMAN_FILTER_GOOD/BEST as separable convolutions

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > Detects and uses PIXMAN_FILTER_NEAREST for all 8 90-degree rotations and > reflections when the scale is 1.0 and integer translation. > > GOOD uses: > > scale < 1/16 : BOX.BOX at size 16 >

Re: [Pixman] [PATCH v13 04/14] pixman-image: Added enable-gnuplot config to view filters in gnuplot

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > If enable-gnuplot is configured, then you can pipe the output of a > pixman-using program > to gnuplot and get a continuously-updated plot of the horizontal filter. > This > works well with

Re: [Pixman] [PATCH v13 02/14] demos/scale: Added pulldown to choose PIXMAN_FILTER_* value

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > This allows testing of GOOD/BEST and to do comparisons between > the basic filters and PIXMAN_FILTER_SEPARABLE_CONVOLUTION settings. > > Signed-off-by: Bill Spitzak >

Re: [Pixman] [PATCH v13 07/14] pixman-filter: Correct Simpsons integration

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > Simpsons uses cubic curve fitting, with 3 samples defining each cubic. This > makes the weights of the samples be in a pattern of 1,4,2,4,2...4,1, and > then > dividing the result by 3. > >

Re: [Pixman] [PATCH v13 08/14] pixman-filter: Corrections to the integral() function

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > The IMPULSE special-cases did not sample the center of the of the region. > This caused it to sample the filters outside their range, and produce > assymetric filters and other errors. Fixing

Re: [Pixman] [PATCH v13 05/14] pixman-filter: Consistency in arg names to integral ()

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > Rename kernel1/2 to reconstruct/sample to match the other functions. > Rename "scale" to "size" to avoid confusion with the scale being applied > to the image, which is the reciprocol of this

Re: [Pixman] [PATCH v13 06/14] pixman-filter: reduce amount of malloc/free/memcpy to generate filter

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > Rearranged so that the entire block of memory for the filter pair > is allocated first, and then filled in. Previous version allocated > and freed two temporary buffers for each filter and did

Re: [Pixman] [PATCH v13 09/14] pixman-filter: Nested polynomial for cubic

On Wed, Feb 10, 2016 at 1:25 AM, wrote: > From: Bill Spitzak > > v11: Restored range checks > > Signed-off-by: Bill Spitzak > Reviewed-by: Oded Gabbay > What's the point of this? All this does is putting ax^2

Re: [Pixman] [PATCH v13 11/14] pixman-filter: Negative subsample values produces scaled result

On Tue, Feb 16, 2016 at 4:45 PM, Bill Spitzak wrote: > I have a new version of this patch, which fixes a math error that > caused it to produce too many samples at small sizes (large scales). I > am not clear if I can submit a v14 of just this patch or I should > instead

Re: [Pixman] [PATCH v13 14/14] demos/scale: default to GOOD and locked-together axis

On Wed, Feb 10, 2016 at 1:25 AM, wrote: From: Bill Spitzak > > This makes the demo match normal behavior of pixman/cairo at startup. > Defaulting to 'locked' makes sense, but in the light of the comments to the earlier patches, defaulting to GOOD doesn't.

Re: [Pixman] [PATCH v14 12/22] pixman-filter: fix subsample_bits == 0

I don't believe this patch is correct. As an example, consider an image with an identity transformation and a cubic filter (which has width 4) with subsample_bits = 0. The current code will compute a matrix [ cubic(-2), cubic(-1), cubic(0), cubic(1) ] Now suppose we are filtering a pixel

Re: [Pixman] [PATCH v14 08/22] pixman-filter: rename "scale" to "size" when it is 1/scale

t; > I really would like to use two different names for these variables as it > is really confusing using the same one. > > > On Fri, Mar 18, 2016 at 8:24 AM, Bill Spitzak <spit...@gmail.com> wrote: > >> >> >> On Thu, Mar 17, 2016 at 10:06 PM, Søren Sandmann &

Re: [Pixman] [PATCH v14 12/22] pixman-filter: fix subsample_bits == 0

r 3, 2016 at 11:17 AM, Søren Sandmann <soren.sandm...@gmail.com> > wrote: > >> I don't believe this patch is correct. >> >> As an example, consider an image with an identity transformation and a >> cubic filter (which has width 4) with subsample_bits = 0. The c

Re: [Pixman] [PATCH v14 10/22] pixman-filter: Correct integration with impulse filters

On Mon, Mar 21, 2016 at 12:29 PM, Bill Spitzak <spit...@gmail.com> wrote: > On Sun, Mar 20, 2016 at 11:36 PM, Søren Sandmann <soren.sandm...@gmail.com > > wrote: > >> On Sun, Mar 6, 2016 at 8:06 PM, <spit...@gmail.com> wrote: >> >>> From: Bill

Re: [Pixman] [PATCH] Fixes to pixman filtering

Hi, I have pushed these patches to master, except (a) I didn't like the changes to the normalization patch, so I went with the one I posted back in April ( https://lists.freedesktop.org/archives/pixman/2016-April/004553.html), and (b) I didn't push the patch adding the filtering dropdown to the

Re: [Pixman] Giving out commit access

> Traditionally this project has been extremely conservative. That depends on what you mean by "extremely conservative". When the pixman git repository was originally set up, everybody with commit access to cairo and xorg got commit access to pixman as well. All of these people still have commit

Re: [Pixman] [PATCH] test: Fix stride calculation in stress-test

Reviewed-by: soren.sandm...@gmail.com On Tue, Jun 12, 2018 at 10:38 AM, Siarhei Siamashka < siarhei.siamas...@gmail.com> wrote: > Currently the number of bits per pixel is used instead of the > number of bytes per pixel when calculating image strides. This > does not cause any real problems, but

Re: [Pixman] Gradient dithering into pixman

will take a longer time frame. I will also be doing a 1.16.0 release > in the coming months, so let me know if this feels like something that > may be achievable in pixman in that time frame; if not we can figure > something else out. I am also at your service if you want help > finalizin

Re: [Pixman] Gradient dithering into pixman

/gradient-proper.png All images were rendered to 565. Søren On Mon, Apr 2, 2018 at 8:40 PM, Søren Sandmann <soren.sandm...@gmail.com> wrote: > Hi, > > If I were still maintainer of pixman, I would definitely stand firm that > the proposed patch is not the right approach. For one, i

Re: [Pixman] [patch] Gradient dithering into pixman

Hi, A long time ago I wrote this: https://lists.freedesktop.org/archives/pixman/2012-July/002175.html about how dithering could be added to pixman. The basic idea is that "dithering" is a property of the destination image, not of the gradient. I still think this is the right way to do it.

Re: [Pixman] [PATCH] pixman-combine: Fix wrong value of RB_MASK_PLUS_ONE.

Hi, The reason this bug doesn't show up in the test suite is that it doesn't have an effect on the output. The purpose of the UN8_rb_ADD_UN8_rb macro is to add two numbers like these: 00aa00bb 00cc00dd together, but to saturate aa+cc and bb+dd to 0xff instead of allowing them to

Re: [Pixman] sRGB scaling without alpha channel?

testing > also with merge request !40): > > https://gitlab.freedesktop.org/pixman/pixman/-/merge_requests/44 > > Thanks, > > > Claude > > On 05/03/2021 23:38, Søren Sandmann wrote: > > There isn't really any guide. > > On Fri, Mar 5, 2021 at 11:00 AM Clau

Re: [Pixman] sRGB scaling without alpha channel?

Hi, You are right that pixman doesn't have support for sRGB formats without an alpha channel. It would make sense to add such support (and it should be straightforward to do so). You might consider biting the bullet and just use an alpha channel. Usually a8r8g8b8 images are faster to work with

Re: [Pixman] sRGB scaling without alpha channel?

in pixman-access.c. Thanks, Søren On Fri, Mar 5, 2021 at 11:00 AM Claude Heiland-Allen wrote: > > Hi Søren, > > On 04/03/2021 19:55, Søren Sandmann wrote: > > You are right that pixman doesn't have support for sRGB formats > > without an alpha channel. It wo

Re: [Pixman] Broken colours on big endian machines since b4a105d

The commit in question is definitely broken and will cause wrong colors of scaled images on big-endian, but I'm not sure who can do anything about it these days. Søren On Tue, Dec 13, 2022 at 11:40 AM Martin Husemann wrote: > > On Sun, Dec 04, 2022 at 11:03:30AM +0100, Martin Husemann wrote: >

[Pixman] [PATCH] Cache the implementation along with the fast paths.

From: Søren Sandmann Pedersen s...@redhat.com When calling a fast path, we need to pass the corresponding implementation since it might contain information necessary to run the fast path. --- pixman/pixman.c | 26 -- 1 files changed, 16 insertions(+), 10 deletions

[Pixman] [PATCH] Split the fast path caching into its own force_inline function

From: Søren Sandmann Pedersen s...@redhat.com The do_composite() function is a lot more readable this way. --- pixman/pixman.c | 200 +- 1 files changed, 107 insertions(+), 93 deletions(-) diff --git a/pixman/pixman.c b/pixman/pixman.c index

Re: [Pixman] FAST_PATH_SAMPLES_COVER_CLIP flag fast_composite_scaled_nearest_*

Siarhei Siamashka siarhei.siamas...@gmail.com writes: Overall looks like a good fix, a few comments below. Thanks for the comments. I'll send a new patch with a long commit log as a follow-up to this message (provided I can make it work with git-send-email), but I'll reply to some specifics

[Pixman] [PATCH 1/2] Extend scaling-crash-test in various ways

From: Søren Sandmann Pedersen s...@redhat.com This extends scaling-crash-test to test some more things: - All combinations of NEAREST/BILINEAR/CONVOLUTION filters and NORMAL/PAD/REFLECT repeat modes. - Tests various scale factors very close to 1/7th such that the source area is very close

Re: [Pixman] [PATCH] ARM: NEON: don't hit general path for r5g6b5 OVER r5g6b5 operation

Would it be possible instead to add a new flag OPAQUE_SAMPLES that would be set whenever the image format is opaque, and then use it along with SAMPLES_COVER_CLIP to add the OPAQUE flag before strength reducing the operator? That would help all the backends, including the general one,

[Pixman] [PATCH] Introduce new FAST_PATH_SAMPLES_OPAQUE flag

From: Søren Sandmann Pedersen s...@redhat.com This flag is set whenever the pixels of a bits image don't have an alpha channel. Together with FAST_PATH_SAMPLES_COVER_CLIP it implies that the image effectively is opaque, so we can do operator reductions such as OVER-SRC. --- pixman/pixman-image.c

[Pixman] [PATCH] Only try to compute the FAST_SAMPLES_COVER_CLIP for bits images

From: Søren Sandmann Pedersen s...@redhat.com It doesn't make sense in other cases, and the computation would make use of image-bits.{width,height} which lead to uninitialized memory accesses when the image wasn't of type BITS. --- pixman/pixman.c | 17 ++--- 1 files changed, 10

[Pixman] [PATCH 1/3] Add pixman_composite_trapezoids().

This function is an implementation of the X server request Trapezoids. That request is what the X backend of cairo is using all the time; by moving it into pixman we can hopefully make it faster. --- pixman/pixman-trap.c | 87 ++ pixman/pixman.h

[Pixman] [PATCH 2/6] Add a test program for pixman_composite_trapezoids().

From: Søren Sandmann Pedersen s...@redhat.com A CRC32 based test program to check that pixman_composite_trapezoids() actually works. --- test/Makefile.am|5 + test/composite-traps-test.c | 253 +++ 2 files changed, 258 insertions(+), 0

[Pixman] [PATCH 3/6] Add support for triangles to pixman.

From: Søren Sandmann Pedersen s...@redhat.com The Render X extension can draw triangles as well as trapezoids, but the implementation has always converted them to trapezoids. This patch moves the X server's triangle conversion code into pixman, where we can reuse the pixman_composite_trapezoid

[Pixman] [PATCH 5/6] Optimize adding opaque trapezoids onto a8 destination.

From: Søren Sandmann Pedersen s...@redhat.com When the source is opaque and the destination is alpha only, we can avoid the temporary mask and just add the trapezoids directly. --- pixman/pixman-trap.c | 133 - 1 files changed, 76 insertions

[Pixman] [PATCH 6/6] Add new public function pixman_add_triangles()

From: Søren Sandmann Pedersen s...@redhat.com This allows some more code to be deleted from the X server. The implementation consists of converting to trapezoids, and is shared with pixman_composite_triangles(). --- pixman/pixman-trap.c | 61

[Pixman] [PATCH 2/3] Move miTriangles to fb as fbTriangles().

From: Søren Sandmann Pedersen s...@redhat.com The fb version simply calls the new pixman_composite_triangles(). This allows us to get rid of miCreateAlphaPicture(). Signed-off-by: Søren Sandmann s...@redhat.com --- fb/fbpict.c |1 + fb/fbpict.h | 10 + fb/fbtrap.c | 109

[Pixman] [PATCH 3/3] Implement fbAddTriangles() in terms of pixman_add_triangles().

From: Søren Sandmann Pedersen s...@redhat.com This allows the remaining triangle-to-trap conversion code to be deleted. Signed-off-by: Søren Sandmann s...@redhat.com --- fb/fbtrap.c | 91 ++- 1 files changed, 9 insertions(+), 82

Re: [Pixman] [PATCH] Add forgotten _mm_empty() calls in the SSE2 fetchers.

Here is a patch series that removes all use of MMX from pixman-sse2.c. This avoids all the emms issues and is likely also a speedup on Windows x64, where MMX intrinsics are not supported and therefore had to be emulated. b/configure.ac|2 b/pixman/pixman-sse2.c

[Pixman] [PATCH 4/8] sse2: Don't compile pixman-sse2.c with -mmmx anymore

From: Søren Sandmann Pedersen s...@redhat.com It's not necessary now that the file doesn't use MMX instructions. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 5242799..8d96647 100644 --- a/configure.ac +++ b

[Pixman] [PATCH 6/8] sse2: Delete obsolete or redundant comments

From: Søren Sandmann Pedersen s...@redhat.com --- pixman/pixman-sse2.c | 137 -- 1 files changed, 0 insertions(+), 137 deletions(-) diff --git a/pixman/pixman-sse2.c b/pixman/pixman-sse2.c index 0753b6d..286dea8 100644 --- a/pixman/pixman-sse2.c

<    1   2   3   4   5   6   >