From: Alan H. <al...@fa...> - 2002-10-31 18:06:37
|
On Thu, Oct 31, 2002 at 06:53:35PM +0100, Michel D=E4nzer wrote: > On Don, 2002-10-31 at 18:38, Alan Hourihane wrote: > > On Thu, Oct 31, 2002 at 01:30:32 +0100, Michel D=E4nzer wrote: > > > On Mit, 2002-10-30 at 17:02, Alan Hourihane wrote: > > > > On Mon, Oct 21, 2002 at 09:16:35 -0700, Ian Romanick wrote: > > > > > On Mon, Oct 21, 2002 at 10:06:13AM -0600, Jens Owen wrote: > > > > > > Ian Romanick wrote: > > > > > > > On Sun, Oct 20, 2002 at 05:09:08PM -0600, Jens Owen wrote: > > > > > > >>Making a direct rendering 3D driver render to a windows bac= king store=20 > > > > > > >>area is a complicated task with very little benefit, IMO. > > > > > > >=20 > > > > > > > Right, but shouldn't purely 2D targets work? I wouldn't th= ink that the > > > > > > > menus in twm are using OpenGL. :) At the very least, if it= 's not supported > > > > > > > at all, when X is started with +bs, shouldn't it say just s= ay no? That's > > > > > > > the problem that I see. The user requests a feature, X say= s it's okay, but > > > > > > > then it's not implemented. > > > > > >=20 > > > > > > TWM isn't a good example, because it can efficiently handle e= xpose=20 > > > > > > events without the klunky backingstore feature enabled. Gran= ted, there=20 > > > > > > exists a small subset of applications that benefit from backi= ng store,=20 > > > > > > but it's a very small set in my experience. Most of the 2D a= pplications=20 > > > > > > that can't handle redraws can often achieve the same effect b= y rendering=20 > > > > > > to pixmaps. > > > > >=20 > > > > > I was just using that as an example the shows the bug I saw. W= ith '+bs' on > > > > > Radeon, the (left-mouse-click) menu is blank until you move the= mouse > > > > > pointer over each of the menu items. > > > > >=20 > > > > > > Would disabling the DRI when backingstore is enabled give the= semantic=20 > > > > > > consistency you're looking for? I don't have a problem with = that,=20 > > > > > > because 99.99% of the users don't need backing store enabled. > > > > >=20 > > > > > I don't think that would help. I commented out the 'Load "dri"= ' and 'Load > > > > > "glx"' lines from my XF86Config file and got the same behavior. > > > >=20 > > > > This looks like the XAA acceleration is to blame. > > > >=20 > > > > If you add=20 > > > >=20 > > > > Option "XaaNoCPUToScreenColorExpandFill" > > > >=20 > > > > Then you get most of the text back, except for the menu bar. It s= eems > > > > that this function isn't honouring transparency information. So w= e could > > > > add NO_TRANSPARENCY to this or find out why it's not working righ= t. > > >=20 > > > I don't see how transparency comes into play with ColorExpandFill, > > > unless maybe transparency is accidentally enabled from a previous > > > operation? Or is it not using the background color? > >=20 > > Exactly, transparency meaning just the foreground color is used, and > > by setting NO_TRANSPARENCY int the CPUTopScreen flags it makes XAA ne= ver=20 > > send the chip a background color of -1. >=20 > I still don't understand: if that's broken, how does all the text I'm > seeing work? Is that all rendered with a background color? More than likely - yes. Alan. |