FreeLists / haiku-appserver / [haiku-appserver] Be's BView and BGLView (and BDirectWindow?) clipping info is faulty

["Rudolf" <drivers.be-hold@xxxxxxxxxxxx>]

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.