[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: Thu, 07 Apr 2005 23:41:24 +0200 CEST

Hi again,

> > Yep: tried that as well. Nogo!
> Which is very strange!

I'll retest this stuff someday just to be absolutely sure: but to be 
honest I was already sure: of course I could have made some stupid 
mistake: although from the results it seems unlikely.

> Okay.
> Have a look at the /boot/optional/sample-code/game_kit/Chart sample 
> (also available as a demo application). It doesn't look like there is 
> anything odd there (ChartWindow::SwitchContext()).

I'll have a look. I tried the 'Stars' optional sample code setup: that 
didn't work for BGLview: saw what I reported here. (look at it's 
DirectConnected function)

> Actually, I remembered wrong: the Chart demo doesn't have a menu bar, 
> although it does have something similar.
Indeed. I looked at it's screen as well. :-)

> A BDirectWindow can have views 
> like any other window - it essentially is exactly like any other 
> window. It only gets direct information on how to access the screen 
> buffer, including the clipping rects.
Well, axel, the BGLView is derived from BView. When I access BView's 
clipping rects I don't have menubar offsets either. I think that doing 
a BView:: call from within BGLView should really give me the info from 
the View I am working in (and no other), shouldn't it?

This view has the size of the entire window including the space taken 
by the menu: in other words: it does not take the menu in account.
For a View I could imagine that would be intended behaviour (?), as I 
could imagine that a DirectWindow doesn't have support for a standard 
menu. Normally, if you create an app using a DirectWindow, this app 
would know if it created a menu or not I suppose. But for me using 
BGLView: I do not know anything about menu's , nor should I have too. I 
don't want to see those details: just give me clipping info that 
accounts for the entire BView (or BGLView, which inherits BView's stuff 
if not 'overwritten' by new functions)
All AFAIK, AFAICT, ATM, with my not so detailed BeOS knowledge of 

Let's put it this way: I got a gut-feeling that they simply forgot 
about that menu, and the signals I get from every direction (class) I 
checked, underline that. And the clipping list: well, I copied it over 
as you suggested, and I _still_ only get the first one: rest remains 
Of course, I realize that officially: a single test is no test at all: 
they should go in tri-somes ;-) So, I am inclined to start questioning 
myself, and retest that sometime. But don;t be surprised, if I got it 
right ;-)

> You have to make sure that the part of the window you want to update 
> directly is not drawn over by a view, ie. that view shouldn't draw at 
> all (by using a transparent view color).
The background is setup in such a way that it's never drawn 
(frontbuffer/window). It doesn't need to, as the backbuffer gets copied 
over it anyway: This gives a 'minor' speedup of rendering of course ;-)

> > Really: I spent a lot of time on BGLView now :-/
> > Thanks anyway..
> Hope that helps. What I don't understand yet, what makes BGLView 
> special? It should only be the GL context that it has plus the 
> backing 
> buffer, right?
What makes it special, is that I am not an app. I am a 'system 
function'. I don't know what an app using BGLView did: so if it drew a 
menu or not. Again: my technical gut-feeling talking here. :)

> > PS: Textures up and running already: driver state is now active 
> > rendering :) (acc func's still turned off though: as they are not 
> > yet 
> > OK it seems)
> > Damn: the suspense is killing me :)
> Hehe - sounds very nice, though :-))
Another update: I've got the line-rendering function (almost) up.: 
GLteapot's FPS rate is drawn accelerated now!
I need to find two errors: depth buffer reading/writing is messing up 
somehow (I had to manually 'pull' the FPS output to the foreground to 
see it), and the sync between the 2D and 3D driver is suddenly down 
again: this must be a 2D command init error. I'll try to narrow both 
down coming monday: off for a holiday-weekend now :)

From the looks of things, it could well be that in a week I report that 
the total driver is up and running! Man, am I curious what fps quake 
and teapot will give me... and what I can do to increase that initial 
'full' rendering speed...

Bye! Have a nice weekend ;-)


> Bye,
>    Axel.

Other related posts: