This is probably either a r128 driver bug or a bug in the acceleration architecture (XAA). If you had access to a non-ATI video card that would be an interesting test. What might fix the problem without resorting to "NoAccel" is to prevent XAA from putting pixmaps in videoram. You can do that with: Option "XaaNoOffscreenPixmaps" If this was a r128 driver bug related to rendering to offscreen videoram or if this was an XAA problem related to rendering to backing store's backing pixmap, that would probably fix the problem. If it were a problem with XAA breaking backing store's wrappers, it probably wouldn't. But there may be other causes - perhaps that driver disables something else when disabling acceleration. >From looking through driver code, it does appear that "NoAccel" also disables some things related to 3D. Mark. On Tue, 11 Apr 2006, Pearson, Paul L-Baker Atlas wrote: > Mark, > > Send me the name and address of a favorite restaurant or bar and I'll > have them open a tab for you to drink a beer with your compadres or eat > a meal. > > The "NoAccel" fixed the problem. Moving the window around is slower, but > the drawing is just as fast and the scrolling is reasonable. The boss is > not happy though. > > Is there something I can do to get the acceleration back in? > > I had removed all the Load commands from the config file. It did not > change anything. > > Thanks, > Paul > > -----Original Message----- > From: Mark Vojkovich [mailto:mvojkovi@xxxxxxxxxxx] > Sent: Tuesday, April 11, 2006 12:42 > To: Pearson, Paul L-Baker Atlas > Cc: devel@xxxxxxxxxxx > Subject: RE: [XFree86] Clipping graphic primitives to visible area of > Window > > > On Mon, 10 Apr 2006, Pearson, Paul L-Baker Atlas wrote: > > > Mark, > > > > I removed the backingstore option from XF86Config. Nothing is > displayed > > in the area of the drawable that is exposed with scrolling. Our > > application does not catch the expose event, it relies on > backingstore. > > So backingstore is partially working. > > > > Our application that uses XPutPixel to draw graphics does not have the > > problem. I can scroll around and everything is available. We use > > XDrawLine to draw the graphics that are missing from the display. I'm > > not sure what we use to display the text - but it is always there when > I > > scroll around. > > > > I removed the three extensions that you had suggested. Now only the > > dotted line is displayed and the text is gone. > > That's weird. I would have expected it to get better. > > > > > Where can I find info on the extensions? I searched for awhile looking > > for descriptions, without luck. > > I don't know of a database of extension descriptions. DBE is > the double-buffer extension. I don't know of any applications that > use it. GLX is the server component of OpenGL. DRI is an extension > related to the implementation of OpenGL that the r128 driver uses. > > You could also try removing the extmod module but that holds > very common extensions like shape and mitshm and some applications > require those to operate. > > You could also try removing the fbdevhw module. I don't > think your driver is using the framebuffer device and I didn't > think that module wrapped any rendering operations, but it > shouldn't hurt to remove it. > > > > > > If the backingstore puts up some of the image - shouldn't it put up > all > > of the image? > > That's probably not the problem. Backing store allocates a > pixmap the size of the drawable. Window rendering that gets > clipped away goes to the backing pixmap. When part of the window > is exposed, that part gets initialized with the backing pixmap > contents instead of sending the client an expose event. I doubt > copying from the backing pixmap is broken. Most likely, rendering > to the backing pixmap is broken. The most common cause of that > being broken is that some extension broke the mechanism which > enables the backing store code to monitor window rendering. > > Could you also try telling the r128 to turn off hardware > acceleration? > That would be: > > Option "NoAccel" > > in the Section "Device" in the XF86Config file. The server will > get very slow, but if it makes the problem go away it narrows > down the problem substantially. > > > Mark. > > > > > We use backingstore for speed of display - these apps are run over the > > network and the geophysical data is large. > > > > Thanks for your help, > > Paul > > > > > > > > -----Original Message----- > > From: Mark Vojkovich [mailto:mvojkovi@xxxxxxxxxxx] > > Sent: Monday, April 10, 2006 12:41 > > To: Pearson, Paul L-Baker Atlas > > Cc: devel@xxxxxxxxxxx > > Subject: Re: [XFree86] Clipping graphic primitives to visible area of > > Window > > > > > > Backing store doesn't really guarantee that you won't get > > expose events. I believe the X11 Protocol specification says > > that enabling backing store merely tells the server that saving > > contents would be "useful" and doesn't guarantee that you won't > > get expose events. A program that isn't capable of handling > > expose events is technically broken. It's probably the case > > that different vendor implementations of backing store make > > different guarantees. XFree86 uses the implementation from > > the X11 sample implementation. > > > > The big question is whether or not XFree86 sent exposures > > when this scrolling occurred (assuming the application requested > > expose events in the first place). If the expose event was > > sent, this is technically not a server bug. The only thing > > weird that I see from your snapshots was that it appears as > > though some rendering operations may have be rendered to the > > backing store while some others might not have. Though another > > explanation is that XFree86 didn't render any of it and the > > text was the only part rerendered by the application after > > the expose event. > > > > I did some quick tests with the only backing store aware > > application I have (the "xv" image viewer) and didn't see any > > obvious problems using NVIDIA's drivers. Sometimes driver or > > extention implementations can break the backing store wrappers, > > but you are using the 'r128' driver which probably isn't modifying > > the wrappers. Some of the other extensions might. You could > > try commenting out the loading of the dbe, dri or glx modules > > in the XF86Config, but I doubt those would be breaking backing > > store wrappers. > > > > My guess is that this is probably a bad app assumption rather > > than a server bug, but I don't have a way to verify that at the > > moment. > > > > Mark. > > > > > > On Mon, 10 Apr 2006, Pearson, Paul L-Baker Atlas wrote: > > > > > Mark, > > > > > > > > > > > > Thanks for the reply. Our applications do depend on backing store > and > > I > > > have enabled it, and it appears to work. If I put a window over the > > > window, everything that was there comes back when the overlay is > > > removed. > > > > > > > > > > > > I have a window which is smaller than my drawable. The window has > > scroll > > > bars. I use text, pixels and graphic primitives (XDrawLine) to > display > > > to the drawable. Everything is displayed in the window. I scroll the > > > window. The text and pixels are displayed, but the graphics done > with > > > the primitives are not displayed. The display acts as if the > > > clip_x_origin, clip_y_origin and clip_mask are being set to the size > > and > > > location of the window. If I scroll the window and force a graphics > > > update, some more primitives are displayed. If I scroll the window > > back > > > to where it was, that which was displayed with the primitives is > gone, > > > text and pixels are there. > > > > > > > > > > > > I've attached four files (hopefully I will remember to attach them) > - > > > the XF86Config file, disp1.png (showing the display before > scrolling) > > > and disp2.png (showing the display after scrolling), and disp3.png > > > (after forcing an update to the scrolled window). > > > > > > > > > > > > Paul Pearson > > > > > _______________________________________________ Devel@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/devel
