Re: [Dri-devel] Re: Backing store on Radeon?

[Alan H. <al...@fa...>]

On Thu, Oct 31, 2002 at 06:02:49PM +0000, Alan Hourihane wrote:
> 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 b=
acking store=20
> > > > > > > >>area is a complicated task with very little benefit, IMO.
> > > > > > > >=20
> > > > > > > > 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 s=
ays it's okay, but
> > > > > > > > then it's not implemented.
> > > > > > >=20
> > > > > > > TWM isn't a good example, because it can efficiently handle=
 expose=20
> > > > > > > events without the klunky backingstore feature enabled.  Gr=
anted, there=20
> > > > > > > exists a small subset of applications that benefit from bac=
king store,=20
> > > > > > > but it's a very small set in my experience.  Most of the 2D=
 applications=20
> > > > > > > that can't handle redraws can often achieve the same effect=
 by rendering=20
> > > > > > > to pixmaps.
> > > > > >=20
> > > > > > 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 t=
he mouse
> > > > > > pointer over each of the menu items.
> > > > > >=20
> > > > > > > Would disabling the DRI when backingstore is enabled give t=
he semantic=20
> > > > > > > consistency you're looking for?  I don't have a problem wit=
h that,=20
> > > > > > > because 99.99% of the users don't need backing store enable=
d.
> > > > > >=20
> > > > > > I don't think that would help.  I commented out the 'Load "dr=
i"' and 'Load
> > > > > > "glx"' lines from my XF86Config file and got the same behavio=
r.
> > > > >=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=
 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 ri=
ght.
> > > >=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, an=
d
> > > by setting NO_TRANSPARENCY int the CPUTopScreen flags it makes XAA =
never=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?
>=20
> More than likely - yes.

But, then it could be a combination problem that involves a specific rast=
er op
with planemask and transparency. But adding NO_TRANSPARENCY does fix the
problem (partly).

Alan.