Hi there, Just an observation I made while implementing clipped back to front buffer rendering for 3D acceleration using BGLView (which works very well now): ->BGLView::DirectConnected()'s info struct's direct=5Fbuffer=5Finfo's clipping info is bad. The member: clipping=5Frect=A0clip=5Flist to be precise. This should be a pointer, not a array. If you look at sample code handling the info here you see it uses it as a pointer as well, but if you look at it's 'content' (array or pointer) you'll find that only the first clipping rect is there. All rects beyond that are zero's or undefined. The number or clipping=5F rects there is reflected by uint32 clip=5Flist=5Fcount, which is correct. BTW: The clipping rects are given in screen-coordinates: wich is very good as this info needs to be fed to the acc engine. I like the 'intended setup', it just has to be fixed... I can imagine the same fault sitting in BDirectWindow BTW: did not check. My workaround just fetches the clipping info from BView::GetClippingRegion::RectAt(x), using it's count as well. This is OK, but gives the coordinates in Window coordinates which means I have to 'translate' now. ---------- OK, here's fault number two: BView's clipping info forgets to take into account a possible existing BMenuBar at the top of the window. This doesn't make sense at all: it nicely tells you where such a menu's drop-down lists are 'presented', but it forgets the menu itself!! The same applies for the one given rect in direct=5Fbuffer=5Finfo, but in another way. It accounts for the diff (20 pixels in height), but it's coordinates are systematically 20 pixels 'low'. (accounts =3D=3D max rect height is 20 less than BView::bounds() (and others) indicate(s). The effect using both 'systems' is that I render on top of the GLTeapot's menu, while the lower 20 pixels of the window contain 'nothing'. This means I have to use another workaround: I just subtract the initial given clipping rect from direct=5Fbuffer=5Finfo from the window's vertical size: hence I get a number of 20 for GLTeapot, but zero for Quake2 (as it should). In case there's no clipping rect I look at the existance of a menubar via BWindow::KeyMenuBar() and set the offset to 20 fixed. =3D=3D=3D=3D=3D=3D=3D=3D That's it. These are the problems I think I got hints about by a Be openGL betatester. Anyway, the workaround (although not perfect) works surprizingly well.... Hope you can do something with this info. Sometime. My take: both problems can be easily fixed, in a compatible way. Rudolf.