Bug#519221: libpixman -- bug recently submitted related to your patch
Hey, André;
Has anything interesting happened in the last ten days? :) Were you
able to get your test setup to reproduce this problem?
2009/3/14 Arren Lex <arrenlex@gmail.com>:
> Hello, Andre:
>
> 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,
> Arren
>
> 2009/3/14 André Tupinambá <andrelrt@gmail.com>:
>> 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?
>>
>> Regards.
>> André Tupinambá
>>
>> On Wed, Mar 11, 2009 at 8:06 PM, Arren Lex <arrenlex@gmail.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?
>>>
>>
>
Reply to: