[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    Re: Buggy repeat modes in Render
From:       Carl Worth <cworth () cworth ! org>
Date:       2008-02-28 12:52:52
Message-ID: 87oda1tf8b.wl%cworth () cworth ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

[Attachment #5 (application/pgp-signature)]

_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[prev in list] [next in list] [prev in thread] [next in thread]