[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
course....
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
invalid.
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 ;-)
Rudolf.
>
> Bye,
> Axel.
>
>
>
Other related posts:
