[haiku-appserver] BDirectWindow / BGLView test
- From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Fri, 12 May 2006 12:43:18 +0200 CEST
Hi,
First off, John Drinkwater's pointer seems not correct. My own tests
indicate that there's no window bordering error at all: maybe he had
incompatible versions of the accelerant and kerneldriver for nvidia
running. Instead, I found this:
In BGLView::DirectConnected(direct_buffer_info *info) currently trouble
exist.
While GLTeapot works correctly at the default window position and size,
moving and resizing the window does not work correctly.
The clipping info members window_bounds and clip_list are _not_ updated
_at all_. And/Or, DirectConnected isn't called after window resize/move
events.
This means that moving a window moves the outline and tab, but not the
content.
I saw this in BGLView using my 3D driver, so I am guessing
BDirectWindow has the same problem (has it?). From the log I can see
directmode is enabled, an initial correct (==compatible to R5/dano)
clipping rect is set. When the teapot is moved this function isn't
called. The teapot spinning comes to a standstill for a (part of)
second or so, then the window is moved, and the pot spins again at the
original position (so outside the window).
What I also saw is that the mouse disappears largely when over the
teapot output, but that's a Haiku problem. (Though that could be fixed
using a lot of cliprect updating and DirectConnected calls: for each
cursor move over the window).
About indirect mode: works OK, that is comparable to R5/dano. With one
exeption: if I drag the window (demo app or so) outside of the screen
partly (right side tested), then it re-appears at the left side. This
doesn't happen in R5/dano, so Haiku probably doesn't clip BView's
cliplist (which I (mis)use here) to only 'display' that part of an
output window that doesn't clip outside the screen's workspace size.
One final remark: The teapot spins at about half the speed it does on
R5/dano (same hardware and drivers). The bottleneck is CPU time on all
systems, so this is a second indication that Haiku 'doubles' the CPU
load for running apps (VLC has that to if you remember). Of course,
it's just my feeling, there might be other/different technical system/
app_server reasons for that.
That's it for now. Just want to let you know the current status here..
I won't investigate myself, I'll be on a break for two weeks in a few
days.
Bye!
Rudolf.
Other related posts:
