Andrea Canciani ranm...@gmail.com writes:
Gradients must have at least one stop.
I think it should also be documented what it actually means for a
gradient to have one stop. (Even with two or more stops, it's not
totally clear what should happen if those stops don't include 0 and 1).
Soren
Andrea Canciani ranm...@gmail.com writes:
Radial gradients whose inner circle is not contained in the outer
circle are in use even if the protocol explicitly forbids them.
Allowing them in the protocol makes it reasonable for programs to
assume that they can be used.
Reviewed-by: Soren
Andrea Canciani ranm...@gmail.com writes:
The Render specification allows single-stop gradients and pixman 0.22
(which the X server depends on) can rasterize them correctly.
Signed-off-by: Andrea Canciani ranm...@gmail.com
Reviewed-by: Soren Sandmann s...@redhat.com
Cyril Brulebois k...@debian.org writes:
diff --git a/fb/fbblt.c b/fb/fbblt.c
index 38271c0..b6e7785 100644
--- a/fb/fbblt.c
+++ b/fb/fbblt.c
@@ -65,6 +65,7 @@ fbBlt (FbBits *srcLine,
int n, nmiddle;
BooldestInvarient;
int startbyte, endbyte;
+
The following changes since commit 8d84fd2566f8466b6152724df7eefc73780df093:
Don't call pixman_disable_out_of_bounds_workaround() anymore (2011-05-25
12:14:05 -0400)
are available in the git repository at:
git://anongit.freedesktop.org/~sandmann/xserver for-keithp
Soren
Keith Packard kei...@keithp.com writes:
On Mon, 23 May 2011 14:34:55 +0200, Soeren Sandmann sandm...@cs.au.dk wrote:
I think Keith said that the merge window for 1.11 closes May 29th
though, so there may not be enough time.
That's the current schedule, with the release happening on August
Dushara Jayasinghe dushara.jayasin...@hydrix.com writes:
I had a look at the pixman code but what's required to add the format
that suits the hardware is not immediately obvious to me. The CPU
peripheral is configured as 1bpp (packed). The MSbit is the left most
pixel.
I'm guessing that I
Jeremy Huddleston jerem...@apple.com writes:
That's quite easy to fix. Too bad that this problem was brought up on
xorg-devel mailing list a few weeks too late for overlapped pixman_blt
to be introduced in pixman 0.22.0. My main concern earlier was about
how to use the newly added pixman
Dushara Jayasinghe dushara.jayasin...@hydrix.com writes:
I'm Working on an iMX.25 (ARM) based embedded platform with
xserver_xorg-server-1.7.5.
I had to make the following mods to servermd.h to reflect the hardware.
#define FBNOPIXADDR
#define IMAGE_BYTE_ORDER MSBFirst
#define
Daniel Stone dan...@fooishbar.org writes:
On Mon, May 02, 2011 at 07:44:15AM -0400, Søren Sandmann wrote:
The interface to these function was was very confusing since it gave
the impression that they initialized the region from a list of boxes,
which they didn't.
This patch changes the
Cyril Brulebois k...@debian.org writes:
Hi,
I guess it might be worth mentioning somewhere in the wiki how to
easily (in an automated fashion) add r-b tags to a range of
commits. Following Jon's suggestion on IRC, I've opted for:
git filter-branch --msg-filter 'add-tag.sh Reviewed-by:
Jeremy Huddleston jerem...@apple.com writes:
Seems simple enough.
Is pixman_disable_out_of_bounds_workaround now just a no-op, or was
the symbol removed from pixman? Hopefully the former, but I wanted to
make sure...
Yes, the function still exists as a no-op.
Soren
Adam Jackson a...@redhat.com writes:
-if (alu == GXcopy pm == FB_ALLONES !reverse
+careful = !((srcLine dstLine srcLine + width * (bpp/8) dstLine) ||
+(dstLine srcLine dstLine + width * (bpp/8) srcLine))
||
+ (bpp % 8);
The srcLine and dstLine
Keith Packard kei...@keithp.com writes:
Signed-off-by: Soren Sandmann s...@redhat.com
Reviewed-by: Keith Packard kei...@keithp.com
I'll wait for you to send a [PULL] request with all of the render
and region changes.
I have sent one. Note that this change:
Please pull the changes below.
Thanks,
Soren
The following changes since commit
918a9c99cf2ebc73acb34b95f597904b93c690d9:
Keith Packard (1):
Merge remote-tracking branch 'jeremyhu/master'
are available in the git repository at:
git://anongit.freedesktop.org/~sandmann/xserver
Adam Jackson a...@redhat.com writes:
Thanks to the magic of unions, this saves 12 or 16 bytes per source-only
picture. Ideally we'll get to the point where we simply use pixman for
this and stop shadowing state in the server, but pixman lacks API for
that at the moment.
I think this patch
Keith Packard kei...@keithp.com writes:
Yes, apparently I did, and also a few in the rootless code. I'll send a
new version pending the outcome of the discussion below.
Thanks.
New version to follow.
Yes, eventually, I think we should. There are currently a few features
of the server
Keith Packard kei...@keithp.com writes:
Fix trapezoid and triangle rendering to windows
My brain is full.
This one is getting urgent.
I don't want to force the issue, but I am going to release pixman 0.21.8
with the corresponding pixman patch in it on Monday at the latest. When
Adam Tkac at...@redhat.com writes:
Hello,
attached patch fixes wrong usage of memcpy. See
https://bugs.freedesktop.org/show_bug.cgi?id=36165 for more info.
Regards, Adam
From b08e7198dc0141b8074d8fdff681019d86655a38 Mon Sep 17 00:00:00 2001
From: Adam Tkac at...@redhat.com
Date: Tue, 12
Michel Dänzer mic...@daenzer.net writes:
On Don, 2011-04-07 at 19:41 +0200, Soeren Sandmann wrote:
The trap offsets change depends on a change to pixman that I will push
as soon as the changes below are in master.
What's the backwards compatibility story there? Will xserver depend
Hi,
Please consider pulling the changes below. Not all of them are reviewed;
the ones that aren't are
- some deletion of unused code in render
- fixes for trapezoid offsets
The trap offsets change depends on a change to pixman that I will push
as soon as the changes below are in
Soeren Sandmann sandm...@cs.au.dk writes:
are available in the git repository at:
git+ssh://sandm...@freedesktop.org/home/sandmann/xserver.git render
The correct URL is
git://anongit.freedesktop.org/~sandmann/xserver.git render
Soren
___
xorg
Dave Airlie airl...@gmail.com writes:
From: Dave Airlie airl...@redhat.com
From what I can see these functions act the exact same way,
that is unless I'm missing something subtle.
As far as I can tell, the difference is that fbCopyWindowProc() always
uses GX_COPY and FB_ALLONES, whereas
Dave Airlie airl...@gmail.com writes:
From: Dave Airlie airl...@redhat.com
these were migrated to mi a while back.
Reviewed-by: Soren Sandmann s...@redhat.com
Soren
___
xorg-devel@lists.x.org: X.Org development
Archives:
Adam Jackson a...@redhat.com writes:
This may be more correct in that it cleans up the Damage. I think it's
less correct in that you break existing clients. FreeDamageExtWin()
deletes the Damage XID, but the spec mentions nothing about magically
garbage-collecting Damages just because their
Tiago Vignatti tiago.vigna...@nokia.com writes:
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
render/render.c | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
Reviewed-by: Soren Sandmann s...@redhat.com
Soren
Søren Sandmann sandm...@cs.au.dk writes:
This patch changes the interface to take just one box and fixes all
the callers accordingly.
Apparently, I missed a RegionCreate() in mirect.c:
- pClip = RegionCreate(NULL, 1);
+ pClip = RegionCreate(NULL);
Also, the open drivers
Søren Sandmann sandm...@cs.au.dk writes:
From: Søren Sandmann Pedersen s...@redhat.com
It is not used anywhere else.
Actually, ignore this one. miCompositeRects() is used indirectly by exa
since exaCompositeRects() is not actually a wrapper of
ps-CompositeRects as I thought.
Soren
Keith Packard kei...@keithp.com writes:
On Wed, 30 Mar 2011 11:34:09 -0400, Søren Sandmann sandm...@cs.au.dk wrote:
This patch adds a new function RegionInitBoxes() and fixes those
instances to call that instead.
What's the memory allocation story here? Does RegionInitBoxes allocate
space
Michel Dänzer mic...@daenzer.net writes:
On Mon, 2011-03-28 at 11:47 -0400, Søren Sandmann wrote:
From: Søren Sandmann Pedersen s...@redhat.com
These calls no longer go through the miComposite(),
I can't seem to find any reference to miComposite() in the Git history.
Do you mean
Maarten Maathuis madman2...@gmail.com writes:
Yes, I think I do, thanks. New version below.
I think you should process pending after doing the rendering operation.
Okay, that makes sense.
Thanks,
Soren
From 4d4cbb145b1bd88da97941ba05f985829ec5a563 Mon Sep 17 00:00:00 2001
From:
Adam Jackson a...@redhat.com writes:
The class field was unused for pixmaps, and we don't have enough classes
to justify a whole uint32 anyway.
Signed-off-by: Adam Jackson a...@redhat.com
You mean usage_hint in the subject line, but other than that,
Reviewed-by: Soren Sandmann
Adam Jackson a...@redhat.com writes:
No more internal users, this can be dropped now.
Signed-off-by: Adam Jackson a...@redhat.com
Reviewed-by: Soren Sandmann s...@redhat.com
Soren
___
xorg-devel@lists.x.org: X.Org development
Archives:
Adam Jackson a...@redhat.com writes:
The mask argument was almost always 0 or (equivalently) M_ANY.
Are they actually equivalent? If you pass 0, then the code uses
M_DRAWABLE, which actually means drawable, which is not an InputOnly
window. But if you pass M_ANY, then InputOnly windows are
Adam Jackson a...@redhat.com writes:
Pretty much every use of 'long' is a bug. Atoms are only 32 bits on the
wire, and though RESTYPE is not a wire type we're only using the low 32
bits of it.
Apart from the uint32_t issue,
Reviewed-by: Soren Sandmann s...@redhat.com
for the series.
James Jones jajo...@nvidia.com writes:
With a scheme like this, the Composite extension itself would become
simply a way to support legacy applications since window redirection
doesn't really mean anything for InputOnly windows.
I would love to see the composite extension extended rather
The following changes since commit
f3d19c0cf3327cceb90f7378f5d8fc0c3e327400:
Keith Packard (1):
Version bumped to 1.10
are available in the git repository at:
git://anongit.freedesktop.org/~sandmann/xserver for-keithp
Søren Sandmann Pedersen (5):
Require pixman 0.21.6
Ville Syrjälä ville.syrj...@nokia.com writes:
On Mon, Feb 28, 2011 at 05:29:56PM -0800, ext Keith Packard wrote:
Ok, let's try to get a bit of protocol review, then look at the library
API, then the server internal APIs and finally the server
implementation. Most of the code already exists,
Peter Hutterer peter.hutte...@who-t.net writes:
From: Adam Jackson a...@redhat.com
Pointer barriers block the movement of a pointer past a certain line,
specified by the barrier. Movement through the barrier may be permitted for
certain directions of movement.
Algorithm used:
For each
Adam Jackson a...@redhat.com writes:
This is pretty much a 'version 0' kind of thing, it looks right to me
but reviews strongly needed.
A conceptual question I have is: What is supposed to happen on
diagonal movement? A possibility is to decompose such movement into a
horizontal and a vertical
Bryce Harrington br...@canonical.com writes:
pixman_image_create_bits() can return NULL under a variety of
circumstances. If this happens, it will segfault when dereferenced in
pixman_image_set_accessors().
http://bugs.freedesktop.org/show_bug.cgi?id=28882
Adam Jackson a...@nwnk.net writes:
On Wed, 2011-01-12 at 08:49 -0500, Søren Sandmann Pedersen wrote:
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
Keith Packard kei...@keithp.com writes:
On Mon, 20 Dec 2010 18:05:38 +0200, ville.syrj...@nokia.com wrote:
Rather than continue my attempts to hack around the issue of incorrect
ClipNotifys during window redirection changes, I decided to tackle the
issue in more proper manner.
This
Andrea Canciani ranm...@gmail.com writes:
The function swapStops repeatedly swaps the color components as
CARD16, but incorrectly steps over them as if they were CARD32.
This causes half of the stops not to be swapped at all and some
unrelated data be swapped instead.
---
render/render.c
Andrea Canciani ranm...@gmail.com writes:
The Render specification allows single-stop gradients and pixman can
correctly rasterize them.
This should be accompanied by a bump in the required pixman
version. 0.20.0 is the first stable version that can correctly do
this.
Also, should this be
Andrea Canciani ranm...@gmail.com writes:
Gradients must have at least one stop.
---
renderproto.txt |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/renderproto.txt b/renderproto.txt
index 9f1f231..f6a9884 100644
--- a/renderproto.txt
+++ b/renderproto.txt
Søren Sandmann sandm...@daimi.au.dk writes:
From: Søren Sandmann Pedersen s...@redhat.com
The functions in these files have not been used since trap
rasterization was moved to pixman. They survived until now to preserve
the server abi.
Forgot to delete renderedge.h from sdksym.sh. New
Matt Turner matts...@gmail.com writes:
So, do we want this patch?
It seems like it does deobfuscate the code a bit, and memcpy is going
to be more efficient than byte-by-byte copies.
Matt
Can I get some Reviewed-bys or Acked-bys?
Reviewed-by: Soren Sandmann sandm...@daimi.au.dk
Andrea Canciani ranm...@gmail.com writes:
Indeed, the code looks mostly fine to me; I couldn't find any
functional problems with it. The main complaints I have:
- In the affine case, some of the computation is done in 32.32, and
some in double precision. Is there any reason for this?
Andrea Canciani ranm...@gmail.com writes:
On Mon, Oct 4, 2010 at 12:07 PM, Andrea Canciani ranm...@gmail.com wrote:
This morning I pushed
http://cgit.freedesktop.org/~ranma42/pixman/log/?h=radial-for-master
It should be ready for master since it is documented, tested (at least
on my
Keith Packard kei...@keithp.com writes:
Frankly, the lack of off-screen pixmaps is probably the principle reason
XAA is faster than EXA for so many chips -- modern desktop apps
generally draw everything off-screen then blt on-screen (and this is
always true with Composite), so you're getting
Chris Wilson ch...@chris-wilson.co.uk writes:
Fixes:
Bug 27313 - random X11 crash (SIGSEGV) when rendering firefox in
pixman/intel
https://bugs.freedesktop.org/show_bug.cgi?id=27313
As pixman does not guard against a fill request outside of the buffer,
we must be be careful and
Hi Marco,
Soeren Sandmann sandm...@daimi.au.dk writes:
There used to be a bug where pixman would miscalculate the
angle. Maybe that's what you are seeing? That bug is fixed in 0.18.0.
I've now upgraded to 0.18.2 but I'm afraid the problem is still there. I'm
not sure whether
Chris Wilson ch...@chris-wilson.co.uk writes:
Some paranoid defense to more easily catch should not happen conditions
from within gdb.
Makes sense to me. (But please also copy pix...@lists.freedesktop.org
on pixman patches).
Thanks,
Soren
Signed-off-by: Chris Wilson
Keith Packard kei...@keithp.com writes:
There isn't any reason to have this in mi. Everything except the file
rename was done with the included script 'fix-miregion'.
Would it be useful to split this commit into two: one that just
renames the file and one that is the result of running the
Keith Packard kei...@keithp.com writes:
There isn't any reason to have this in mi. Everything except the file
rename was done with the included script 'fix-miregion'.
Didn't realize that the hand-rolled changes commit used to be part
of this. The comment I have on that part is that it seems to
Keith Packard kei...@keithp.com writes:
There isn't any reason to have this in mi. Everything except the file
rename was done with the included script 'fix-miregion'.
There is a search-and-replace bug here:
- * to miValidateTree. Bob Scheifler changed the representation to be more
+ * to
Chris Wilson ch...@chris-wilson.co.uk writes:
On Fri, 21 May 2010 11:44:39 -0400, Adam Jackson a...@redhat.com wrote:
Context:
https://bugzilla.redhat.com/show_bug.cgi?id=533879
If you've got a 24bpp framebuffer, you poor misguided soul you, then you
have a conundrum. Pixmaps are
Keith Packard kei...@keithp.com writes:
On Tue, 11 May 2010 14:12:52 -0400, Adam Jackson a...@nwnk.net wrote:
I just want it to not trivially crash my server. I could care less
about correctness for this.
Then I think the only needed fix is to check for the trivial loop:
index
Hi Matthias,
The following patch fixes Novell bug 568811:
VNC Installation aborts right in the middle due to an assertion in
Xvnc/libpixman
The bug seems occur only on *very* special occasions (in this case, only
in SLES, but *not* in SLED, which is based on the same code basis...).
Matthias Hopf mh...@suse.de writes:
This patch in particular, I don't think shold ship with no testing at
all. So please revert it, and we can consider it again for 0.19.x.
I'm fine with that if you consider it problematic. Given that the
situation it changes should actually not occur at
Matthias Hopf mh...@suse.de writes:
On Mar 24, 10 19:19:15 +0100, Soeren Sandmann wrote:
However, what happens if the code would have been compiled with -NDEBUG?
Is the code path stable with empty regions? If it is, it can be argued
that the patch is not necessary, but it could also
Julien Cristau jcris...@debian.org writes:
On Fri, Mar 19, 2010 at 11:24:25 -0700, Jeremy Huddleston wrote:
How does one ensure that X Errors report human readable text versions of
major / minor opcodes?
ie, how do I make sure that something like this is reported:
Major opcode
Hi,
There is now a pixman mailing list of everything related to pixman. I
subscribed some people - roughly based on the criterion has committed
at least twice and hasn't vanished.
To subscribe:
http://lists.freedesktop.org/mailman/listinfo/pixman
The archives will eventually be
From: Søren Sandmann Pedersen sandm...@redhat.com
Rather than the region code having its own little debug system, move
all of it into pixman-private where there is already return_if_fail()
macros etc. These macros are now enabled in development snapshots and
nowhere else. Previously they were
Benjamin Otte o...@redhat.com writes:
just out of interest: Why do you use negative flags like
FAST_PATH_NO_PAD_REPEAT instead of positive ones like
FAST_PATH_PAD_REPEAT?
This is because the flags fields in the fast path tables is really a
list of properties that must be satisfied for the
Adam Jackson a...@redhat.com writes:
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/common/xf86AutoConfig.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/common/xf86AutoConfig.c
b/hw/xfree86/common/xf86AutoConfig.c
index 1c4595e..384c7e5
Hi,
The bitmasks branch here:
http://cgit.freedesktop.org/~sandmann/pixman/log/?h=bitmasks
contains the initial reorganization in prepration for the full flags
branch. Specifically, it adds the flag fields to the fast path tables,
and it changes the fast path checks to be based on
Michael Cree mc...@orcon.net.nz writes:
What I do see is that the variables a, r, g and b are essentially
declared unsigned char (what I presume uint8_t is typedefed to) and a
calculation is performed that will lose its intended result due to
shifting an unsigned char more bits to the left
Previously they would be evaluated at 8 bits and then expanded.
Soren
---
pixman/pixman-image.c |2 +-
pixman/pixman-private.h|5 -
pixman/pixman-solid-fill.c | 35 ---
3 files changed, 37 insertions(+), 5 deletions(-)
diff --git
The Render spec says this about alpha maps:
The alpha channel of alpha-map is used in place of any alpha
channel contained within the drawable for all rendering
operations.
Which says that the alpha channel of the drawable is directly replaced
with that of the alpha map.
Hi,
There is a couple of bugs in bugzilla where bugs in the X server
triggered asserts in the pixman region code. It is probably better to
let the X server survive this. (In fact, I thought I had disabled them
for 0.16.0, but apparently not).
The patch below uses these rules:
- In _stable_
Keith Packard kei...@keithp.com writes:
Sorry for replying to myself again -- I meant to describe the effect of
this patch on source operands.
What this does is use the entire pixmap as the source operand and then
adjust either the source transform (if present) or source coordinates to
Keith Packard kei...@keithp.com writes:
On 30 Nov 2009 15:52:20 +0100, Soeren Sandmann sandm...@daimi.au.dk wrote:
If you clip to the screen pixmap, then you will need to adjust the
transformation to account for the coordinates of the drawable no
longer being right. Or ignore it, as you
Keith Packard kei...@keithp.com writes:
On 27 Nov 2009 12:33:24 +0100, Soeren Sandmann sandm...@daimi.au.dk wrote:
(a) The window can be partically offscreen and partially covered by
other windows, which means the set of pixels in it that can be
legally accessed is a possibly
Siarhei Siamashka siarhei.siamas...@gmail.com writes:
Yeah, we should probably at have at least two CRC32 values, one for
the 2 million case, and one for a 100 million case that could run
overnight.
It might also be interesting to have many more than two values, and
store them in a
Siarhei Siamashka siarhei.siamas...@gmail.com writes:
Hello,
This patch provides more than 2x performance improvement for this particular
case (terminal, bitmap font, 16bpp desktop color depth). Benchmarked on
ARM Cortex-A8.
Tested for correctness on both big and little endian systems.
Siarhei Siamashka siarhei.siamas...@gmail.com writes:
Reviews appreciated. I'd also appreciate if people can test that it
still compiles and works on ARM as I had to make some changes blindly
there.
It compiles fine, but requires a minor fix for ARM NEON. These two lines need
a
When the destination buffer is either a8r8g8b8 or x8r8g8b8, we can use
it directly instead of fetching into a temporary buffer. When the
format is x8r8g8b8, we require the operator to not make use of
destination alpha, but when it is a8r8g8b8, there are no
restrictions.
This is approximately a 5%
Hi,
Here:
http://cgit.freedesktop.org/~sandmann/pixman/commit/?h=sse__8_
is a patch that adds an sse2 x 8 x fast path. This is a
small speedup on the swfdec-youtube benchmark:
Before:
[ 0]image swfdec-youtube5.7895.806 0.20%6/6
After:
[
Siarhei Siamashka siarhei.siamas...@gmail.com writes:
write-through cache for it (with a simple kernel patch) improves scrolling
and moving windows performance by 4x-5x factor (unless shadow framebuffer is
used, which is also not good for performance).
What is the issue with the shadow
Siarhei Siamashka siarhei.siamas...@gmail.com writes:
First introduce something like 'pixman_init' function. Right now CPU type
detection is done on the first call to the function. It introduces some
minor overhead by having an extra pointer check on each function call.
Another problem is
Guillem Jover guil...@hadrons.org writes:
Generalize to catch all .pc files. Add more tests.
This looks good to me, but the patch doesn't apply for me. Feel free
to push it yourself if you have commit access; otherwise, please
upload the patch somewhere, and I'll apply it.
Thanks,
Soren
Bill Spitzak spit...@gmail.com writes:
In general I consider tiled apis to make things unnecessarily
complicated. The majority of cairo input is packed into an array. You
either need to require images to be padded out to a multiple of tile
size, or you need to greatly complicate things with
Hi,
How about this one in pixman-trap.c _pixman_edge_multi_init()
Shouldn't the type of nx be 'pixman_fixed_48_16_t' not 'int'?
As I read the code, it is dividing two pixman_fixed_48_16 values and
the result of that is an integer and not a fixed point value.
If we were actually using the 48
Hi,
As far as I am aware pixman 0.16.2 is ready to be released. If anyone
know of any other bugs or fixes that need to go in, let me know.
Otherwise, please test this snapshot:
http://www.freedesktop.org/~sandmann/pixman-0.16.1.tar.gz
especially if you have an unusual platform such as ARM
Hi Benjamin,
All of this sounds good to me. Below are a few comments on how YUV
formats could be integrated in pixman.
1) Add extensive YUV support to pixman
Extensive YUV support would be a very useful addition to pixman. Apart
from the benefits you listed, I think it also makes sense to have
Emacs crashes if you run it on a composited desktop without render acceleration.
I'll push to both 1.7 and master unless there are objections.
Soren
commit a9ba24ef7d5153abe2684927de5be23ad7b50735
Author: Søren Sandmann Pedersen sandm...@redhat.com
Date: Thu Sep 10 21:42:42 2009 -0400
Hi,
Now that pixman 0.16.0 is out, it's time to look at what comes next.
0.16.2
We'll need an 0.16.2 release to fix ARM, Solaris and Windows x64 build
issues. People should feel free to push these fixes to master and
cherry-pick them to the new 0.16 branch. Once we have all the fixes
in, I'll
Rainman Lee rainman@gmail.com writes:
I thought the performance for rotating should be improved, especially
on windows.
I run a test which painted a rotated image pattern from 0 degree to
360 degree, with fast filter, and no antialias.
cairo takes 3448ms, but GDI+ takes only 1411ms, more
Hi,
Pixman 0.15.16 contains the last bits of refactoring, so from now on,
there will be a coding style enforced. The coding style is similar to
cairo's, with the main difference being that braces go on their own
line always. Ie.,
if (...)
{
}
and not
if (...) {
Aaron Plattner aplatt...@nvidia.com writes:
On Tue, Jun 09, 2009 at 09:50:05AM -0700, Soeren Sandmann wrote:
Pixman has a feature where you can set accessor functions on an image
and all pixel access will then go through those functions. It's used
exclusively for wfb.
Until now
Julien Cristau jcris...@debian.org writes:
Wouldn't it be better to use pixman_version_string() here? The version
used at build time doesn't seem like it should matter.
Good catch, I'll fix.
Thanks,
Soren
___
xorg-devel mailing list
Adam Jackson a...@nwnk.net writes:
On Tue, 2009-06-16 at 11:32 +0200, da...@protonic.nl wrote:
You probably want to start with something like the Xorg fbdev driver and
then start bolting on acceleration paths that call down into the EGL
driver. Getting that to interact well with GLX
Maarten Maathuis madman2...@gmail.com writes:
Does this make transformed composite (XRGB source) with no extending
ok again with regards to the black pixels that a lot of hw sample
outside the texture?
It doesn't change that.
Previously it switched from being ok to being bad, i'm just
The new clipping rules:
- client clips happen after transformation
- pixels unavailable due to the hierarchy are undefined
The first one is implemented in pixman; the second one is realized by
making a copy of window sources (to prevent out-of-bounds access).
---
configure.ac |
Ignore the hierarchy clip, and always apply any client clip after
transformation and repeating.
---
render/mipict.c | 40
1 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/render/mipict.c b/render/mipict.c
index e0d40ae..71f3de7 100644
---
Simon Thum simon.t...@gmx.de writes:
For the more artistic cases directed at perceptual qualities (like
some gradients, but not the WM shadow gradient!), luma modulation is
of course desirable. But there are better tools for this purpose, like
the L*a*b* space. So why go to such great lengths
Maarten Maathuis madman2...@gmail.com writes:
I had a closer look, and the only worry is fbRasterizeEdges.
Ok, I'll buy that it could be a real performance issue if the mask
ends up thrashing back and forth between host and video
memory.
However, trapezoid rasterization always happens to a
Simon Thum simon.t...@gmx.de writes:
Soeren Sandmann wrote:
- bits_image_fetch_pixels() then calls a low-level pixel fetcher
whose job it is to convert from whatever the image format is to
PIXMAN_a8r8g8b8.
Just a question: does that imply algos will work on 8-bit data? I'm
1 - 100 of 107 matches
Mail list logo
