From: Søren Sandmann Pedersen
This is a simple demo that displays a checkboard with a projective
transformation.
---
demos/Makefile.am|5 +-
demos/checkerboard.c | 152 ++
2 files changed, 156 insertions(+), 1 deletions(-)
create mode
Here are some more patches I've had sitting around for a while. They
basically make the composite-test a little prettier by using an image
of a parrot instead of a yellow rectangle. Screenshot:
http://www.daimi.au.dk/~sandmann/composite-test.png
The parrot came from here
http://www.flickr.c
From: Søren Sandmann Pedersen
---
demos/composite-test.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/demos/composite-test.c b/demos/composite-test.c
index bba90c5..f6c3804 100644
--- a/demos/composite-test.c
+++ b/demos/composite-test.c
@@ -4,8
From: Søren Sandmann Pedersen
The 1000_1000 name is a relic from before the refactoring.
---
pixman/pixman-fast-path.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/pixman/pixman-fast-path.c b/pixman/pixman-fast-path.c
index eac8dea..0a134ed 100644
--- a/pixman
cu writes:
> I have temporarily turned off NEON optimizations (strangely, they only
> amounted to about 5% of rendering time
> in this specific case).
> I plan to build a test case as soon as time permits.
>
> It does seem to break on the same address (or at least same instruction
> content), I'l
From: Søren Sandmann Pedersen
This function converts from a8r8g8b8 to non-premultiplied RGBA (the
PNG or GdkPixbuf format that has the channels in this order: R, G, B,
A in memory regardless of the computer's endianness). The function's
new name is a8r8g8b8_to_rgba_np().
---
test/util
From: Søren Sandmann Pedersen
Use pixman_image_get_format() instead of image->bits.format.
---
demos/gtk-utils.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/demos/gtk-utils.c b/demos/gtk-utils.c
index 0e7cb5c..b321989 100644
--- a/demos/gtk-utils.c
+++ b/de
From: Søren Sandmann Pedersen
Instead of inlining a copy of that functionality.
---
demos/Makefile.am |6 +++---
demos/gtk-utils.c | 41 -
2 files changed, 11 insertions(+), 36 deletions(-)
diff --git a/demos/Makefile.am b/demos/Makefile.am
index
From: Søren Sandmann Pedersen
In the computation:
srtot += RED_8 (pixel) * f
RED_8 (pixel) is an unsigned quantity, which means the signed filter
coefficient f gets converted to an unsigned integer before the
multiplication. We get away with this because when the 32 bit unsigned
result is
From: Søren Sandmann Pedersen
Unpremultiplying a superluminescent pixel can result in values greater
than 255.
---
test/utils.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/test/utils.c b/test/utils.c
index cc0365a..c1bf6dc 100644
--- a/test/utils.c
Matt Turner writes:
>> - add_8_8: Here too you also only do the optimization in the edge
>> cases.
>
> I can't (at least with lowlevel-blt-bench) measure any performance
> improvements by doing the optimization in the middle of scanlines. I
> suppose it's because the optimization would only ski
Siarhei Siamashka writes:
>> + /* a1 = src */
>> + lbu t0, 0(a2) /* t0 = mask */
>> + beqz t0, 222f /* if (t0 == 0) */
>> + addiu a2, a2, 1
>> + beq t0, t5, 22f /* if (t0 == 0xff) */
>> + move t1, a1
>> + lhu t1,
From: Søren Sandmann Pedersen
https://bugs.freedesktop.org/show_bug.cgi?id=46905
---
Makefile.am |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index df8677a..88ff897 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,6 +21,10
"Fan, Chun-wei (范君維)" writes:
> I have managed to come up with some patches to add Visual C++
> 2008/2010 project files to build pixman as a DLL with these compilers
> under x86 and x86-64 configurations, with x86-MMX support (on x86
> only) and SSE2 support.
>
> In the first patch:
> -Updated pi
Matt Turner writes:
> I started porting my src__0565 MMX function to SSE2, and in the
> process started thinking about using SSE3+. The useful instructions
> added post SSE2 that I see are
> SSE3: lddqu - for unaligned loads across cache lines
I don't really understand that instructi
Nemanja Lukic writes:
> From: Nemanja Lukic
Thanks for the bug fix. One nitpick though: We need a bit more detail in
the commit message about what the bug was and how it was fixed.
Thanks,
Soren
___
Pixman mailing list
Pixman@lists.freedesktop.org
h
-0.25.4.tar.bz2
SHA1: f5304bb3bf9e23bd1f56b449659c56e22babb5a4 pixman-0.25.4.tar.gz
SHA1: 88d852eaa05aee61cd1b7380ade7b0b0701a30fd pixman-0.25.4.tar.bz2
GPG signature:
http://cairographics.org/snapshots/pixman-0.25.4.tar.gz.sha1.asc
(signed by Søren Sandmann Pedersen
z2
SHA1: ebd1b438a28aca0099777b1e383c60d4fcb88196 pixman-0.25.6.tar.gz
SHA1: e05dae328ff58836a167a3409be7df98bba38f09 pixman-0.25.6.tar.bz2
GPG signature:
http://cairographics.org/snapshots/pixman-0.25.6.tar.gz.sha1.asc
(signed by Søren Sandmann Pedersen )
Git:
git://git.freedesktop
Matt Turner writes:
> Given a pixel with only the red component of these values, the results
> are off-by-one.
>
> 0x03 -> 0x19 (0x18)
> 0x07 -> 0x3A (0x39)
> 0x18 -> 0xC5 (0xC6)
> 0x1C -> 0xE6 (0xE7)
>
> (Same for blue, and green has many more cases)
>
> It uses
> R8 = ( R5 * 527 + 23 ) >> 6;
>
Søren Sandmann writes:
>> Given a pixel with only the red component of these values, the results
>> are off-by-one.
>>
>> 0x03 -> 0x19 (0x18)
>> 0x07 -> 0x3A (0x39)
>> 0x18 -> 0xC5 (0xC6)
>> 0x1C -> 0xE6 (0xE7)
>>
>> (Same for blu
Matt Turner writes:
> I'm not sure if we want
>
> #ifndef _MSC_VER
> pack_4x565
> pix_add_mul
> #else
> pack_4x565
> pix_add_mul
> #endif
>
> or if we want
>
> #ifndef _MSC_VER
> pack_4x565
> #else
> pack_4x565
> #endif
>
> #ifndef _MSC_VER
> pix_add_mul
> #else
> pix_add_mul
> #endif
>
> Soren?
Matt Turner writes:
> On Fri, May 18, 2012 at 2:41 PM, Matt Turner wrote:
>> If not compiling with -march=iwmmxt, the configure test will still pass,
>> thinking that the __builtin_arm_* intrinsic is a function instead of
>> generating a single instruction. Since no linking is done, the configur
Cyril Brulebois writes:
> but there's no parrot.jpg in the tarball. Maybe it would make
> sense to add it to EXTRA_DIST too so that an extracted tarball
> matches a bit more what's in git?
Good point - I've added it.
Søren
___
Pixman mailing list
Pix
Siarhei Siamashka writes:
> On Wed, May 16, 2012 at 12:37 AM, Siarhei Siamashka
> wrote:
>> On Mon, May 14, 2012 at 9:17 PM, Nemanja Lukic
>> wrote:
>>> Is this small improvement worth making this code vulnerable to endian
>>> issues?
>>
>> If you are already satisfied with this level of perf
"Lukic, Nemanja" writes:
> I added more explanation in the commit message for that commit.
Thanks, I have pushed it to master (with some minor formatting changes)
along with the bilinear optimization patch.
Thanks,
Søren
___
Pixman mailing list
Pixma
There is a couple of places where the test suite uses the
pixman_image_fill_* functions to initialize images. These functions
can fail, and will do so if the "fast" implementation is disabled.
So to make sure the test suite passes even using
PIXMAN_DISABLE="fast", use pixman_image_composite32() wi
balbir kumar writes:
> Hi All,
>
> I am trying to draw an image [Ht: 576, Wt: 575, DeviceRGB, Data...] with
> an
> image-soft-mask [Ht: 576, Wt: 575, DeviceGray, Data...]. So, far I am
> unable
> to figure out how to use pixman to do it. Could someone please give me
> some
> po
, including Alan
Coopersmith, Andrea Canciani, Bobby Salazar, Chun-wei Fan, Colin
Walters, Ingmar Runge, Jeremy Huddleston, Matt Turner, Naohiro Aota,
Nemanja Lukic, and Søren Sandmann Pedersen,
Please send bug reports to pixman@lists.freedesktop.org or file them at
https://bugs.freedesktop.org
From: Søren Sandmann Pedersen
Now that we have the full image flags available, the SSE2 and MMX
iterators can simply check against SAMPLES_COVER_CLIP_NEAREST (which
is computed in pixman_image_composite32()) instead of comparing all
the x/y/width/height parameters.
---
pixman/pixman-mmx.c
From: Søren Sandmann Pedersen
When pixman_image_composite32() is called some flags are computed that
indicate various things about the composite operation that can't be
deduced from the image flags themselves. These additional flags are
not currently available to iterators. All they can
From: Søren Sandmann Pedersen
When a destination image I has an alpha map A, the following rules apply:
- If I has an alpha channel itself, the content of that channel is
undefined
- If A has RGB channels, the content of those channels is
undefined.
Hence in order to compute
From: Søren Sandmann Pedersen
This test tests the new glyph cache and compositing API. Much of this
test is intending to making sure that clipping and alpha map handling
survive any optimizations that may be added to the glyph compositing.
---
test/Makefile.sources |1 +
test/glyph-test.c
From: Søren Sandmann Pedersen
Bypass much of the overhead of pixman_image_composite32() by only
computing the composite region once instead of once per glyph, and by
only looking up the composite function whenever the glyph format or
flags change.
As part of this, the
From: Søren Sandmann Pedersen
When adding glyphs to the mask, bypass most of the overhead of
pixman_image_composite32() by:
- Only looking up the composite function when the glyph changes either
format or flags.
- Just intersecting the glyph rectangle with the destination rectangle
instead
From: Søren Sandmann Pedersen
This way it can be used in other tests.
---
test/blitters-test.c | 31 +--
test/utils.c | 39 +++
test/utils.h |7 ++-
3 files changed, 46 insertions(+), 31 deletions
From: Søren Sandmann Pedersen
This new API allows entire glyph strings to be composited in one go
which reduces overhead compared to multiple calls to
pixman_image_composite32().
The pixman_glyph_cache_t is a hash table that maps two keys (a "font"
and a "glyph" key, bu
From: Søren Sandmann Pedersen
Make _pixman_image_get_solid() faster by special-casing the common
cases where the image is SOLID or a repeating a8r8g8b8 image.
This optimization together with the previous one results in a small
but reproducable performance improvement on the xfce4-terminal-a1
Hi,
The following patch series add a new API for caching and compositing
glyphs. Compositing entire strings of glyphs in one go is a
substantial reduction in overhead by itself, but the series also
contains a few optimizations that exploit glyph specific properties of
the compositing operations.
From: Søren Sandmann Pedersen
This commit adds some new inline functions to maintain a doubly linked
list.
The way to use them is to embed a pixman_link_t into the structures
that should be linked, and use a pixman_list_t as the head of the
list.
The new functions are
pixman_list_init
Søren Sandmann writes:
> The following patch series add a new API for caching and compositing
Forgot to mention that the patches are also avaiable here:
http://cgit.freedesktop.org/~sandmann/pixman/log/?h=glyph3
Soren
___
Pixman mailing l
Alan Coopersmith writes:
> On 05/30/12 04:41 PM, Søren Sandmann wrote:
>> +# define OFFSET_OF(type, member) \
>> +((unsigned long)(&(((type *)0)->member))
>> +#endif
>
> Why not use the offsetof(type, member) macro that C89
Jeremy Huddleston writes:
> Yes, clang-3.0 has the bug, and pixman's configure script should be detecting
> that and disabling the code path that tickles the bug. In my case,
> config.log shows that the check is behaving correctly:
>
> configure:12684: checking whether to use MMX intrinsics
>
Ryan Schmidt writes:
> On May 30, 2012, at 20:33, Søren Sandmann wrote:
>
>> Maybe the difference is that you are using "-O0" where Ryan is using
>> "-O2". The "K" constraint requires the argument to be compile-time
>> constant, whic
Behdad Esfahbod writes:
> Looks nice. I don't see you updating the mru list though.
It's actually added in the two optimizations later in the series. I used
to have them in the API patch too, but they must have gotten lost in the
rebases. I'll add them there too.
Thanks,
Soren
___
Behdad Esfahbod writes:
> On 05/30/2012 07:41 PM, Søren Sandmann wrote:
>> While this is going on, the cache must be "frozen", which basically
>> means that glyphs will not be evicted from it. That way, the
>> application can be sure that all the glyphs are a
Here is a new version of the glyph API patch series. Changes:
- Use C89 macro offsetof() as suggested by Alan
- Move glyphs to front of the MRU list, even in the non-optimized
commit as suggested by Behdad
- Add glyphs with (white IN glyph) ADD mask to handle mixed format
glyphs, also sugges
From: Søren Sandmann Pedersen
This commit adds some new inline functions to maintain a doubly linked
list.
The way to use them is to embed a pixman_link_t into the structures
that should be linked, and use a pixman_list_t as the head of the
list.
The new functions are
pixman_list_init
From: Søren Sandmann Pedersen
This new API allows entire glyph strings to be composited in one go
which reduces overhead compared to multiple calls to
pixman_image_composite32().
The pixman_glyph_cache_t is a hash table that maps two keys (a "font"
and a "glyph" key, bu
From: Søren Sandmann Pedersen
This way it can be used in other tests.
---
test/blitters-test.c | 31 +--
test/utils.c | 39 +++
test/utils.h |7 ++-
3 files changed, 46 insertions(+), 31 deletions
From: Søren Sandmann Pedersen
This test tests the new glyph cache and compositing API. Much of this
test is intending to making sure that clipping and alpha map handling
survive any optimizations that may be added to the glyph compositing.
V2: Evaluating lcg_rand_n() multiple times in an
From: Søren Sandmann Pedersen
When a destination image I has an alpha map A, the following rules apply:
- If I has an alpha channel itself, the content of that channel is
undefined
- If A has RGB channels, the content of those channels is
undefined.
Hence in order to compute
From: Søren Sandmann Pedersen
When adding glyphs to the mask, bypass most of the overhead of
pixman_image_composite32() by:
- Only looking up the composite function when the glyph changes either
format or flags.
- Only using a white source when the glyph format is different from
the mask
From: Søren Sandmann Pedersen
Make _pixman_image_get_solid() faster by special-casing the common
cases where the image is SOLID or a repeating a8r8g8b8 image.
This optimization together with the previous one results in a small
but reproducable performance improvement on the xfce4-terminal-a1
From: Søren Sandmann Pedersen
Bypass much of the overhead of pixman_image_composite32() by only
computing the composite region once instead of once per glyph, and by
only looking up the composite function whenever the glyph format or
flags change.
As part of this, the
From: Søren Sandmann Pedersen
Instead of caching these fetchers in the image structure, and then
have the iterator getter call them from there, simply change them to
be iterator getters themselves.
This avoids an extra indirect function call and lets us get rid of the
get_scanline_32/64 fields
"Antti S. Lankila" writes:
> Attached is a simple patch that produces around 20 % Mpix/s
> improvement for wide path processing due to significant optimization
> of pixman_expand. On my i7 laptop, we go from:
>
>> src__2x10 = L1: 62.08 L2: 60.73 M: 59.61
>> ( 4.30%) H
"Antti S. Lankila" writes:
> Thanks for the code review. This new patch (attached) should have all
> of these accounted for.
Pushed to master with one additional change: inwidth -> in_width and
outwidth -> out_width.
Thanks,
Søren
___
Pixman mailing
Jeremy Huddleston writes:
> http://tinderbox.x.org/builds/2012-06-10-0003/logs/pixman/#check
>
> It looks like something in c2230fe..367b78f has caused ppc and ppc64
> pixman to fail make check. Unfortunately, I don't have the cycles to
> bisect the issue at this point.
The glyph test is new in
Bill Spitzak writes:
> A problem with sRGB for line art is that drawing an inverted drawing
> will not look correct to users. White lines and text will look much
> too thin, while black lines and text look thicker. This appears to be
> because humans invert images in perceptual space. It is possi
It turns out that this was caused by initializing the destination
buffer in glyph test using random uint32_t values rather than random
uint8_t values. Patch follows.
Soren
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.or
From: Søren Sandmann Pedersen
The destination buffer was initialized with 32 bit data, so it started
out different on big-endian vs. little endian. Fix that by
initializing the buffer with random bytes instead.
---
test/glyph-test.c | 10 +++---
1 files changed, 7 insertions(+), 3
From: Søren Sandmann Pedersen
Found by coverity:
https://bugzilla.redhat.com/show_bug.cgi?id=756069
---
test/stress-test.c |1 +
1 file changed, 1 insertion(+)
diff --git a/test/stress-test.c b/test/stress-test.c
index 0b48da3..7fc067e 100644
--- a/test/stress-test.c
+++ b/test/stress
"Antti S. Lankila" writes:
> On 09.06.2012 14:16, Antti S. Lankila wrote:
>
>> Currently the color space processing is just a cheap integer hack
>> with gamma 2.0. It is sufficient for testing purposes, but not
>> production quality. I'm leaning towards tabularizing the official
>> sRGB-to-linear
Matt Turner writes:
> The registers -- yes. The 8-byte aligned loads and stores I'm not
> sure. Can you do 8-byte aligned loads and stores to/from SSE
> registers?
I believe movq can use SSE registers.
> Indeed, runtime generation would be great. Something like LLVM or orc
> would be interestin
hong shao writes:
> Making all in pixman
> /usr/bin/perl 8 < > pixman-combine32.c || ( pixman-combine32.c; exit 1)
> Syntax error: redirection unexpected
> *** Error code2
>
I looks like your make doesn't understand $(lastword $+).
Soren
___
Pixman m
Siarhei Siamashka writes:
> This is also a very useful test, but it effectively requires to have
> an alternative double precision implementation for all the pixman
> functionality to be verified. For bilinear scaling it means that at
> least various types of repeats need to be handled, etc. And
"Antti S. Lankila" writes:
> Can do. However, there will be a few places then which need to be
> taught about the new ARGB_SRGB pixel type, unless we also modify the
> PIXMAN_FORMAT_TYPE to filter out the color space bits. I did this to
> keep changes minimal. I added the PIXMAN_FORMAT_SPACE macr
Bill Spitzak writes:
> A problem is the pseudo-random starting point. This is necessary so
> that you do not get vertical stripes when the rows have the same
> data. But if you want your composites to not change, it has to be
> deterministic. I'm not sure but perhaps a hash of the y coordinate of
Chris Wilson writes:
> On Mon, 25 Jun 2012 02:00:27 +0300, Siarhei Siamashka
> wrote:
>> Does it actually make sense? I remember somebody was strongly opposing
>> the idea of spawning threads in pixman in the past, but can't find
>> this e-mail right now.
You may be remembering an IRC discussi
Siarhei Siamashka writes:
> Also 7-bit bilinear interpolation precision still allows a nice SSSE3
> optimization, which can be implemented later to get even more speed.
Presumably you mean pmaddubsw, but isn't it a problem that the weights
can go from 0 to 128 inclusive? That is, if one weight i
Søren Sandmann writes:
> The main concern from me is making sure that it doesn't cause issues in
> the X server, which is known to do wacky things with signals and
> possibly threads. But the answer to that is to just put it in and get it
> tested.
In some limited testing of th
Siarhei Siamashka writes:
> There is also one thing to investigate. It was likely also a problem
> earlier, but may become worse when going to lower interpolation
> precision. Right now the position between pixels is rounded down by
> throwing away lowest bits when converting it to bilinear weigh
Søren Sandmann writes:
> For bilinear filtering, the question of rounding down is mostly
> irrelevant because we need both the pixel below and above. In this case
> step 3 and 4 become simply a truncation.
This is not true actually. To get the lower pixel, 0.5 is subtracted,
and
Søren Sandmann Pedersen writes:
> git://people.freedesktop.org/~sandmann/pixman
>
> in the branch "cpudetectfiles".
This got mangled by git send-mail. It should have said:
TL;DR:
Please test these patches, especially on MSVC, XO-1, MIPS and
mobile ARM.
Alan Coopersmith writes:
> On 06/29/12 01:44 PM, Søren Sandmann Pedersen wrote:
>> I was looking at making use of some of the newer x86 SIMD instruction
>> sets and realized that (a) we don't ever call cpuid on x86-64, we just
>> assume that MMX and SSE2 are present,
&
Alan Coopersmith writes:
> Don't you need to update the feature flags set in the getisax code to match
> the renaming you did to cpu_features_t ?
Yes, I do, and I also need to initialize features to 0 and reinstate the
results variable.
Thanks,
Soren
___
Siarhei Siamashka writes:
> On Tue, Jun 26, 2012 at 6:13 AM, Jeff Muizelaar
> wrote:
>>
>> On 2012-06-25, at 7:44 PM, Siarhei Siamashka wrote:
>>
>>> These are the test patches for switching to 7-bit bilinear
>>> interpolation precisions. The first patch makes bilinear precision
>>> configurabl
From: Søren Sandmann Pedersen
stress-test current almost never composites anything because the clip
rectangles and transformations are such that either
_pixman_compute_composite_region32() or analyze_extent() will return
FALSE.
Fix this by:
- making log_rand() return smaller numbers so that
From: Søren Sandmann Pedersen
In fast_composite_tiled_repeat() if the source image is less than a
certain constant width, a clone is created which is then
pre-repeated. However, the source image's palette, if it has one, is
not cloned, so for indexed images, the pre-repeating would crash.
Matt Turner writes:
> +SIMPLE_BILINEAR_FAST_PATH (SRC, a8r8g8b8, a8r8g8b8,
> mmx__ ),
> +SIMPLE_BILINEAR_FAST_PATH (SRC, a8r8g8b8, x8r8g8b8,
> mmx__ ),
> +SIMPLE_BILINEAR_FAST_PATH (SRC, x8r8g8b8, x8r
Jeff Muizelaar writes:
> Siarhei wrote this patch and we've been using it in the Mozilla tree since
> May.
>
> Before this patch it was often faster to scale and repeat in two
> passes because each pass used a fast path vs. the slow path that the
> single pass approach takes. This makes it so th
Siarhei Siamashka writes:
>> In the case of 2-pass scaling, typically all the pixels from the
>> source image are participating in calculations (unless M >= 2 * N,
>> which is 2x+ downscaling). So the number of horizontal interpolation
>> operations is M * N (each source scanline gets horizontall
Søren Sandmann Pedersen writes:
> The changes to x86 are the most involved. There is now a
> pixman_cpuid() function that uses inline assembly on GCC and the
> cpuid__ intrinsic on MSVC. The assembly is written such that it will
> work on both 32 and 64 bit; the main change required
Hi,
> I have prepared a patch to generate an AmigaOS4 shared library from
> the pixman sources. My first question is whether you would, in
> principle, include something like this in the main git? And if, how
> can I best distribute the patch? The patch is quite large as it is
> about 300k is size
Sebastian Bauer writes:
> Declare functions *_inverse() and *_contains_rectangle() in the same
> way as the other functions are declared. This doesn't imply any
> semantic changes. It's just a unification of coding styles.
Pushed, thanks.
Soren
___
P
Knut Petersen writes:
> Søren, the bad commit was supposed to fix a gcc -O0 compile problem, but it
> breaks
> gcc -O0 compilation here. Reverting f9c91ee2 fixes the problem for me.
Thanks for the bug report. Can you please try the following patch and
let me know if it fixes the problem?
Sore
From: Søren Sandmann Pedersen
When not optimizing, write _mm_shuffle_pi16() as a statement
expression with inline assembly. That way we avoid
__builtin_ia32_pshufw(), which is only available when compiling with
-msse, while still allowing the non-optimizing gcc to understand that
the second
Søren Sandmann writes:
> I can't think of a way to save the value of a 32 bit register that both
> works on x86-32 and doesn't lose the upper 32 bits on x86-64, so in the
> new version below, there are some #ifdefs to deal with this issue.
And that version didn't work o
Hi,
> Here's a work in progress that adds dithering for 16 bit
> gradients. This does a 2x2 ordered dither in the same way that Skia
> does. Skia and Coregraphics also do dithering of 32bit gradients which
> I expect would also be useful for pixman in the future too.
> This patch adds a partial i
Antti Lankila writes:
> From 693af3995b46d531342d68ac83b794113d0a7a90 Mon Sep 17 00:00:00 2001
> From: "Antti S. Lankila"
> Date: Sun, 10 Jun 2012 22:31:38 +0300
> Subject: [PATCH] Add support for sRGB surfaces
This mostly looks good to me. The main highlevel comment I have is that
I'd like the
Antti Lankila writes:
> Okay. I'll start splitting the work into pieces. I'll submit each as a
> separate mail/patch as I get the changes done. Here's the first,
> probably the least controversial change:
Pushed, thanks.
Soren
___
Pixman mailing list
After pushing the remaining sRGB patches (thanks Antti!) I wanted to
make an 0.27.2 release, but it turned out that distcheck needed enough
fixes that I didn't want to just push them without at least the
pretense of review.
I'll push these patches and release 0.27.2 in a couple of days of
nobody p
From: Søren Sandmann Pedersen
Otherwise make distcheck doesn't pass.
---
pixman/Makefile.am |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/pixman/Makefile.am b/pixman/Makefile.am
index deacf87..843711a 100644
--- a/pixman/Makefile.am
+++ b/pixman/Makefile.am
@@
From: Søren Sandmann Pedersen
The rectangles in the clip region set in set_general_properties()
would sometimes overflow, which would lead to messages like these:
*** BUG ***
In pixman_region32_union_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_erro
From: Søren Sandmann Pedersen
glyph-test would sometimes set a solid image as an alpha map, which is
not allowed. When this happened and the debug spew was enabled,
messages like this one would be generated:
*** BUG ***
In pixman_image_set_alpha_map: The expression
From: Søren Sandmann Pedersen
This allows code that uses these macros to build when timers are
disabled.
---
pixman/pixman-private.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/pixman/pixman-private.h b/pixman/pixman-private.h
index d5e6a72..2da467c 100644
--- a
From: Søren Sandmann Pedersen
This demo program composites a bunch of trapezoids side by side with
and without gamma aware compositing.
---
demos/Makefile.am |2 +
demos/srgb-trap-test.c | 119
2 files changed, 121 insertions(+), 0
From: Søren Sandmann Pedersen
This makes show_image() deal with more formats than just a8r8g8b8, in
particular, a8r8g8b8_sRGB can now be handled.
Images that are passed to show_image with a format of a8r8g8b8_sRGB
are displayed without modification under the assumption that the
monitor is
: 7cec4c9df3aacb3e53da45654f9a0943ef4c7c47 pixman-0.27.2.tar.gz
SHA1: 974a1ad699953a40ca9e481181aef9964ff54a2a pixman-0.27.2.tar.bz2
GPG signature:
http://cairographics.org/snapshots/pixman-0.27.2.tar.gz.sha1.asc
(signed by Søren Sandmann Pedersen )
Git:
git
SeongWon Cho writes:
> Do you have any plans on releasing stable 0.28.0 soon?
The plan is to release 0.28.0 in the beginning of November.
Soren
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
301 - 400 of 887 matches
Mail list logo
