[haiku-appserver] Be's BView and BGLView (and BDirectWindow?) clipping info is faulty
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Thu, 07 Apr 2005 11:14:02 +0200 CEST
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[1] to be precise. This should be a
pointer, not a array[1]. 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.
Other related posts:
