From: Alan H. <al...@fa...> - 2002-10-30 16:07:19
|
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 backing store > > >>area is a complicated task with very little benefit, IMO. > > > > > > Right, but shouldn't purely 2D targets work? I wouldn't think 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 say no? That's > > > the problem that I see. The user requests a feature, X says it's okay, but > > > then it's not implemented. > > > > TWM isn't a good example, because it can efficiently handle expose > > events without the klunky backingstore feature enabled. Granted, there > > exists a small subset of applications that benefit from backing store, > > but it's a very small set in my experience. Most of the 2D applications > > that can't handle redraws can often achieve the same effect by rendering > > to pixmaps. > > I was just using that as an example the shows the bug I saw. With '+bs' on > Radeon, the (left-mouse-click) menu is blank until you move the mouse > pointer over each of the menu items. > > > Would disabling the DRI when backingstore is enabled give the semantic > > consistency you're looking for? I don't have a problem with that, > > because 99.99% of the users don't need backing store enabled. > > 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. This looks like the XAA acceleration is to blame. If you add Option "XaaNoCPUToScreenColorExpandFill" Then you get most of the text back, except for the menu bar. It seems that this function isn't honouring transparency information. So we could add NO_TRANSPARENCY to this or find out why it's not working right. Alan. |