Buggy repeat modes in Render

[Carl Worth]

On Thu, 28 Feb 2008 12:51:30 +0100, Michel Dänzer wrote:
> You can't tell XAA from EXA (or GLucose, ...) though. AFAIR one of those
> workarounds already penalized EXA for an XAA bug, it would be nice if
> that kind of thing didn't happen again.

Yeah. And lots of X servers have been penalized due to the re-epoching
of the VendorRelease for example. I don't want to repeat things like
that again either.

> I'd rather not - as someone else mentioned, I think the idea of clients
> behaving differently depending on driver version is rather horrid.

Fair enough.

> Maybe the results could be cached, e.g. by storing them in atoms.
> 
> This is the same philosophy used by the autotools - in order to find out
> if something works, just try it instead of guessing from other things.

That's really not an unreasonable idea.

The only immediate flaw I see is that several of the things that have
pushed us into doing workarounds in cairo are things where the X
server behavior is particularly anti-social. The current case I'm
trying to characterize is one where cairo's extend-reflect puts the X
server into some VM-thrashing loop, (or perhaps it's trying to do a
memcpy with an overflowed size or something), that crashes the server
or locks up the machine entirely.

So we don't really want every cairo application pushing all of those
buttons on startup. Unless everybody wants a little extra
encouragement to deploy fixes for every X server bug that cairo has
hit...

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20080228/d310c042/attachment.pgp>