Andrea Canciani writes:
> I'm still unsure if we want this optimization... I think that the gradient
> optimization is more likely to provide performance improvements.
The gradient optimization is probably more important since gradients
(along with bilinear filtering) are the two things that sta
On Fri, Jan 21, 2011 at 11:56 PM, Soeren Sandmann wrote:
> Andrea Canciani writes:
>
>> > The old code had more lines of code for this part, but on the other hand
>> > all
>> > this code was in a single place as opposed to being spread around. In some
>> > ways, the new code is a bit more limiti
Andrea Canciani writes:
> > The old code had more lines of code for this part, but on the other hand all
> > this code was in a single place as opposed to being spread around. In some
> > ways, the new code is a bit more limiting. For example, fetching directly to
> > destination without intermed
Andrea Canciani writes:
> I also tried to implement the "parameter, then color" idea:
> http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/itergradient&id=3bcd40c2a5842519167c6ab37d2ad4628667b108
>
> It is currently far from perfect (in particular the "-1" hardcoded to
> clear...),
> but
On Fri, Jan 14, 2011 at 1:46 PM, Siarhei Siamashka
wrote:
> On Wednesday 12 January 2011 12:46:39 Soeren Sandmann wrote:
>> Siarhei Siamashka writes:
>> > > 15 files changed, 743 insertions(+), 470 deletions(-)
>> >
>> > On the other hand, I'm not so happy about the implementation. The number
>>
On Wednesday 12 January 2011 12:46:39 Soeren Sandmann wrote:
> Siarhei Siamashka writes:
> > > 15 files changed, 743 insertions(+), 470 deletions(-)
> >
> > On the other hand, I'm not so happy about the implementation. The number
> > of lines of code as well as the complexity has increased, and
Siarhei Siamashka writes:
> > 15 files changed, 743 insertions(+), 470 deletions(-)
>
> On the other hand, I'm not so happy about the implementation. The number of
> lines of code as well as the complexity has increased, and the performance
> seems to have dropped a little bit in some of the ca
On Thursday 06 January 2011 04:09:38 Søren Sandmann wrote:
> The following patch series changes the scanline access to be based on
> iterators instead of direct calls to virtual functions. There are
> several benefits to this:
>
> - Since destination iterators are different from source iterators,
Andrea Canciani writes:
> In "Move get_scanline_32/64 to the bits part of the image struct."
> (commit ffbd7a2722fff502f1ad6200ba3a009704df9d66)
> _pixman_image_get_scanline_generic_64 could easily be improved
> by pixman_contract()-ing mask8 only if it is not NULL instead of returning
> in case
> Iterators gets initialized with a buffer which can always contain at
> least "width" pixels. This is sufficient for current image types,
> but future image types might need additional space.
>
> Would it be possible to have the general_composite_rect ask to the
> iterator about how much memory i
On Sat, Jan 8, 2011 at 12:15 PM, Soeren Sandmann wrote:
>> Iterators gets initialized with a buffer which can always contain at
>> least "width" pixels. This is sufficient for current image types,
>> but future image types might need additional space.
>>
>> Would it be possible to have the general
On Thu, Jan 6, 2011 at 3:43 AM, Soeren Sandmann wrote:
> Søren Sandmann writes:
>
>> The following patch series changes the scanline access to be based on
>> iterators instead of direct calls to virtual functions. There are
>> several benefits to this:
It also provides a natural place to initial
Søren Sandmann writes:
> The following patch series changes the scanline access to be based on
> iterators instead of direct calls to virtual functions. There are
> several benefits to this:
The patches are also available in the iterators3 branch here:
http://cgit.freedesktop.org/~sandmann/pixm
The following patch series changes the scanline access to be based on
iterators instead of direct calls to virtual functions. There are
several benefits to this:
- Since destination iterators are different from source iterators, we
can fix the bug we have currently, where destination transformat
14 matches
Mail list logo
