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

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 11 Apr 2005 10:47:32 +0200 CEST

Hi there Philippe!

> Sorry for being slow to react.
Glad to see a response anyway :)

> I guess you run your tests using your Mesa-based (3.2 or even latest 
> version)
> nVidia HW accelerated libGL.so's, right?
> Then, that's right, the BGLView::DirectConnected() method receive the 
> view's
> window owner clipping rects list. From beBook :
> "If the BGLView is in a BDirectWindow, you should call this from your
> BDirectWindow::DirectConnected() function to let OpenGL update the 
> window
> properly."
> So, that's expected. If no other window overlap yours (no menu popup, 
> no other
> window), you'll always get one single clipping rect, in screen 
> coordinates
> space, corresponding to the window whole content area (parent view).

To be exact, there's is _no_ rect (mostly) if the window is not 
visible, there is _one_ if no one overlaps and no menu items are open, 
and there stays _one_ if there is overlay and/or menu stuff. The count 
variable is workign though. Zero, one or whatever count needed for a 
complete list.

> Included your BGLView's view obviously (;-) ) but also any others 
> optional views
> attached to the window (MenuBar view, for instance).
> To be usefull, my Mesa's BGLView::DirectConnected() must be 
> implemented to
> compute the view clipping rect list in screen coordinates space. That 
> the kind
> of values the renderer (HW or software) needs.

So: I (of course) implemented that routine now. But you have to 
elaborate on what you think about implementing. I am using the struct 
given to me in that routine 'as a user': I'd say the system should fill 
that out, _not_ me(!). But, as it's incorrectly filled out, I myself 
get the rects from the view instead.
I hope, Philippe, you can find the time to do some testing yourself 
with dumping the rects inside your software mesadriver. You should be 
able to see the errors I reported. Please confirm (or deny) my report 
after testing yourself?

Also: make sure you have a close look at the size of the first clipping 
rect reported: you'll find that it matches the View minus menu, but the 
location is at the left-top of the menu, instead of being just below 

> It should be just a matter of intersecting direct_info's clipping 
> rect list with
> the screen-translated view clipping rect list.
I don't understand what you are saying here. Maybe you should just have 
a look at my code (and do a test for yourself ;-)

> But, currently, it's not implement. That's a known unsupported 
> feature of Mesa
> at the moment.
hehe: it's implemented, that routine. I am using it (with my 
workarounds) and it's working perfectly over here.

> Yep. My bad for not had put a comment in BGLView::DirectConnected() 
> about what
> should REALLY be done there. I didn't considered supporting (Be's) 
> Direct mode
> in Mesa's BGLView much urgent, as it does make sense only in 
> not double-buffered) rendering which is... old-ish.

I don't know how it should be: I just know that with both GLteaport and 
Quake2  BGLView::DirectConnected() gets called. You have to understand 
that _also_ in double buffering you cannot live without the clipping 
info it provides: as from the driver's point of view: every 
doublebuffered context is (also) single buffered!

Bye! (thanks again for being here :)


Other related posts: