[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.
> 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
> BGL_SINGLE (aka
> 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 :)
Rudolf.
Other related posts:
