[prev in list] [next in list] [prev in thread] [next in thread]
List: xfree-xpert
Subject: Re: [Xpert]Re: [Dri-devel] Backing store on Radeon?
From: Alan Hourihane <alanh () fairlite ! demon ! co ! uk>
Date: 2002-10-31 17:38:08
[Download RAW message or body]
On Thu, Oct 31, 2002 at 01:30:32 +0100, Michel Dänzer 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 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.
>
> 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?
Exactly, transparency meaning just the foreground color is used, and
by setting NO_TRANSPARENCY int the CPUTopScreen flags it makes XAA never
send the chip a background color of -1.
Alan.
_______________________________________________
Xpert mailing list
Xpert@XFree86.Org
http://XFree86.Org/mailman/listinfo/xpert
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic