On Wed, 2010-09-29 at 14:39 +0200, Soeren Sandmann wrote:
> I think the right fix is to use different flags for solids and
> non-solids.
Fine by me.
--
--
From: Jonathan Morton
jonathan.mor...@movial.com
___
Pixman mailing list
Pixman@lists
Siarhei Siamashka writes:
> Standard fast paths can be used in the following two cases:
> a) pixels outside image boundaries are not accessed
> b) solid source (special cases of 1x1 image with repeat set)
> And can't be when:
> c) pixels outside image boundaries are accessed (excluding solid case
Siarhei Siamashka writes:
> On Tuesday 28 September 2010 17:24:14 Siarhei Siamashka wrote:
> > The flags in pixman are implemented in such a way that they all have some
> > kind of "positive" meaning, indicating that the operation is going to be
> > more simple than the general case in one way or
On Tuesday 28 September 2010 17:24:14 Siarhei Siamashka wrote:
> The flags in pixman are implemented in such a way that they all have some
> kind of "positive" meaning, indicating that the operation is going to be
> more simple than the general case in one way or another. Having more flags
> set on
On Tuesday 28 September 2010 14:55:41 Siarhei Siamashka wrote:
> On Monday 27 September 2010 17:51:32 Jonathan Morton wrote:
> > If I may inject an alternative point of view into this lively
> > discussion...
> >
> > I think the current flags system is overcomplicated for the common case.
> > If a
On Monday 27 September 2010 17:51:32 Jonathan Morton wrote:
> If I may inject an alternative point of view into this lively
> discussion...
>
> I think the current flags system is overcomplicated for the common case.
> If any one of a wide variety of flags is set for an operation, this
> excludes
If I may inject an alternative point of view into this lively
discussion...
I think the current flags system is overcomplicated for the common case.
If any one of a wide variety of flags is set for an operation, this
excludes a huge number of potential fastpaths. Meanwhile we seem to
have a probl
On Friday 24 September 2010 19:39:10 Soeren Sandmann wrote:
> Siarhei Siamashka writes:
> > On Wednesday 22 September 2010 17:56:20 Soeren Sandmann wrote:
> > > Siarhei Siamashka writes:
> > > > But right now setting PAD repeat for everying will cause serious
> > > > performance problems for pixm
Siarhei Siamashka writes:
> On Wednesday 22 September 2010 17:56:20 Soeren Sandmann wrote:
> > Siarhei Siamashka writes:
> > > But right now setting PAD repeat for everying will cause serious
> > > performance problems for pixman, because it will stop using simple
> > > non-transformed fast path
Hi Bill,
It seems to me that you are looking at the problem from a bit different angle.
The whole issue is that the developers of radeon drivers are recommending
to use PAD repeat in applications in order to avoid some performance problems
on this type of hardware. But if the application develope
On Wednesday 22 September 2010 17:56:20 Soeren Sandmann wrote:
> Siarhei Siamashka writes:
> > But right now setting PAD repeat for everying will cause serious
> > performance problems for pixman, because it will stop using simple
> > non-transformed fast paths.
> >
> > This patch tries to addres
What I do in OpenGL is draw a rectangle (well two triangles) textured
with the image with PAD repeat. Outside the rectangle is 0,0,0,0. This
produces the sharp edge I wanted and allows full acceleration to be
used. Because OpenGL and DirectX assume that such sharp edges are how
images will be d
Bill Spitzak writes:
> This is in fact what users expect, and also what other graphics
> libraries are doing (which explains why the hardware is supporting PAD
> directly).
The reason Render's NONE is difficult to accelerate in hardware is
that for formats without alpha (such as x8r8g8b8), Rende
Siarhei Siamashka writes:
> From: Siarhei Siamashka
>
> Without this fix, setting PAD repeat on a source image prevents
> the use of any nonscaled standard fast paths, affecting performance
> a lot. But as long as no pixels outside the source image boundaries
> are touched by the compositing op
On Sep 21, 2010, at 9:04 PM, Siarhei Siamashka wrote:
But now returning back to this issue. Ideally, PAD repeat would be a
better
default instead of NONE. Just because NONE repeat is a bit strange and
hard to accelerate in hardware. This is one example from
freedesktop.org
bugzilla (and th
From: Siarhei Siamashka
Without this fix, setting PAD repeat on a source image prevents
the use of any nonscaled standard fast paths, affecting performance
a lot. But as long as no pixels outside the source image boundaries
are touched by the compositing operation, all the repeat types
behave the
16 matches
Mail list logo
