[cairo] potential bug in cairo relative to intel drivers

[Mike Gualtieri]

Chris,

Sure no problem.  I will need to create a smaller testing version of the app
to demonstrate the problem first.  The code is actually for something I'm
developing for work, so I'll need to strip out the unnecessary parts first.


- Mike

--
On Fri, Jul 31, 2009 at 3:49 AM, Chris Wilson <chris at chris-wilson.co.uk>wrote:

> On Thu, 2009-07-30 at 14:02 -0700, Carl Worth wrote:
> > On Thu, 2009-07-30 at 16:57 -0400, Mike Gualtieri wrote:
> > > Setting NoAccel to true fixes the issue.  When it is set to false (the
> > > default) the problem occurs.
> >
> > Yes. :-)
> >
> > If "the problem" means "blending the scaled image with the destination
> > in the case of EXTEND_NONE and cairo_paint()" then that's not a bug at
> > all. It's the expected behavior that EXTEND_NONE and cairo_paint() will
> > give you this blending when you scale up.
> >
> > So if setting NoAccel to true makes that blending go away, then yes,
> > that does sound like a bug in the NoAccel case.
> >
> > Does that make sense? Or am I still misunderstanding something?
>
> Although from the description, thank you Mike for being clear and
> concise, we have a good idea of exactly what bug we are looking for, we
> have been developing a tool that should making this kind of bug report
> easier in future. The idea is that the user runs cairo-trace on the
> application and captures a trace which will contain sufficient
> information to replicate the drawing instructions that exhibit the bug.
> And then we can feed this trace through a tool called cairo-test-trace
> which can be run against two X servers in parallel and compare the
> output after every context. Once it has found a discrepancy, it will
> save the images of the differing surfaces and a minimal trace to
> reproduce the error. (At the moment this is likely to find a difference
> in rendering long before we hit the scaling bug! :(
>
> One of the goals for the future, is to then run a technique called
> delta-debugging, which essentially performs a binary bisection on the
> trace, to reduce the trace even further down to the precise minimum
> required to reproduce a bug. (The only difficulty here is that to do the
> bisection efficiently we need to be able to determine illegal cuts,
> faster than simply executing the trace and hitting an error -- that is
> to bisect the state rather than the script.)
>
> Mike, I would appreciate if if you could find the time to download
> cairo-trace either from the 1.9.2 snapshot, or from git and capture a
> trace from your application:
>  # cairo-trace --profile ./how-to-exhibit-bug [args]
> Note that the trace will capture everything drawn, so be careful no to
> include any confidential information, or anything else you might not
> want to distribute.
>
> That will produce a file called ./how-to-exhibit-bug.$pid.lzma which
> will probably be too large to attach here, so upload it or send it to
> me, and I can see how well our tools fare. Already I can see that we're
> encouraging people to use --profile more often than not, so it might be
> worth making that the default.
>
> Thanks,
> -ickle
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20090731/df540876/attachment.htm