On 2/10/12 11:15 AM, Pierre Ossman wrote:
>> You mean this code?
>>
>> if (ig->willTransform()) {
>> ig->translatePixels(pixels, &solidColor, 1);
>> pixels = (PIXEL_T *)&solidColor;
>> }
>>
>> I don't follow. As you can see, it changes the value of the "pixels"
>> pointer so th
On Thu, 09 Feb 2012 14:58:06 -0600
DRC wrote:
>
> You mean this code?
>
> if (ig->willTransform()) {
> ig->translatePixels(pixels, &solidColor, 1);
> pixels = (PIXEL_T *)&solidColor;
> }
>
> I don't follow. As you can see, it changes the value of the "pixels"
> pointer so
On 2/9/12 6:34 AM, Pierre Ossman wrote:
> On Sun, 05 Feb 2012 15:32:52 -0600
> DRC wrote:
>
>> Perhaps I'm still missing something, because after examining the patch
>> again, I don't see where the original buffer corruption was occurring or
>> how your patch fixes it. Part of the difficulty in
On Sun, 05 Feb 2012 15:32:52 -0600
DRC wrote:
> Perhaps I'm still missing something, because after examining the patch
> again, I don't see where the original buffer corruption was occurring or
> how your patch fixes it. Part of the difficulty in analyzing this patch
> is that you seem to have t
I've stared at the code yet again and can't see where the corruption was
occurring prior to 4841. I understand and agree with you setting the
various method arguments to const. That's not the issue. The issue is
that I don't understand why some of the code in tightEncode.h was moved
around-- par
Perhaps I'm still missing something, because after examining the patch
again, I don't see where the original buffer corruption was occurring or
how your patch fixes it. Part of the difficulty in analyzing this patch
is that you seem to have taken the opportunity to move a lot of things
around to c
I think it would be interesting to see if there is a relation between this
and the issue discussed in bug 3414789... If I can make time next week
I'll to look into it.
-brian
On Fri, Feb 3, 2012 at 10:00 AM, Pierre Ossman wrote:
> On Tue, 31 Jan 2012 05:03:06 -0600
> DRC wrote:
>
> >
> > I h
On Tue, 31 Jan 2012 05:03:06 -0600
DRC wrote:
>
> I have not seen this, either in high-level or low-level tests. Please
> explain how to reproduce it.
The easiest way to provoke it is with a composited desktop and a solid
blue background. I've been using the Gnome 3 fallback on Fedora 16.
--
On 1/31/12 2:57 AM, Pierre Ossman wrote:
> On Mon, 30 Jan 2012 15:55:11 -0600
> DRC wrote:
>
>> How does it not work so well? You can't just commit potentially
>> disruptive patches after the code has been stabilized without first
>> opening them up for discussion.
>>
>> I expect a more detailed
On Mon, 30 Jan 2012 15:55:11 -0600
DRC wrote:
> How does it not work so well? You can't just commit potentially
> disruptive patches after the code has been stabilized without first
> opening them up for discussion.
>
> I expect a more detailed answer than your commit log below.
>
The tight e
How does it not work so well? You can't just commit potentially
disruptive patches after the code has been stabilized without first
opening them up for discussion.
I expect a more detailed answer than your commit log below.
On 1/30/12 7:58 AM, ossm...@users.sourceforge.net wrote:
> Revision: 48
11 matches
Mail list logo
