On Thu, Oct 31, 2002 at 06:13:12PM +0000, Alan Hourihane wrote: > 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änzer wrote: > > > On Don, 2002-10-31 at 18:38, Alan Hourihane wrote: > > > > 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. > > > > > > 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. > > But, then it could be a combination problem that involves a specific raster op > with planemask and transparency. But adding NO_TRANSPARENCY does fix the > problem (partly).
I've found the root of the problem: backing store was being initialized before XAA. This caused the backing store and XAA code to fight resulting in the visual rendering errors that Ian (and others) saw. The fix was to move the backing store initialization to after XAA is intialized. The same problem occurred on both the Rage 128 and Radeon. I've checking in the changes to the DRI tree and will check them into the XFree86 tree with my next set of fixes. If you find other problems, please post them here and I'll take a look. Kevin ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
