Bug#519221: libpixman -- bug recently submitted related to your patch
Earlier, I provided my xorg configuration and Xorg.0.log (they were
not addressed to you, but you can find them on the bug's page). They
may help you to set up an environment.
There is no colour depth specified in my xorg configuration, so it's
whatever it defaults to -- I guess 24?
I have a laptop running debian (intel video drivers) where this bug
does not appear. Therefore, it looks like something particular to my
configuration. I hope you can reproduce it on your test setup, but if
not, I am happy to try anything you suggest or apply any patches.
Thanks for all your help,
2009/3/14 André Tupinambá <firstname.lastname@example.org>:
> Hi Arren,
> The SSE2 code is really faster than C equivalent, but performs better
> with images larger than 16 pixels wide. Since to get the SSE2 best
> performance we need to align the destination address in 16 bytes. So
> all operations are made in three loops, one for the alignment, one for
> the bulk operation and the last one for operate the last pixels. But
> with small images, all operations are done within the alignment and
> tail loops. That is what is going on on this case, I guess.
> I'm creating and environment to trying to get this bug. Which color
> depth are you using?
> André Tupinambá
> On Wed, Mar 11, 2009 at 8:06 PM, Arren Lex <email@example.com> wrote:
>> Sorry, I left out this piece of possibly useful information:
>> I have a dual-monitor setup -- one is 1280x1024 and one is 1680x1050.
>> I usually run konsole maximized across the larger monitor, and it is
>> terribly slow like that. When I make the konsole window smaller, the
>> problem becomes less noticeable (but even when the window is very
>> small, you can easily tell the problem is still there because the text
>> makes waves as it scrolls). This behaviour leads me to think it might
>> be falling back to software rendering for painting the text now. Is
>> that possible?