[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


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 
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 
This means that moving a window moves the outline and tab, but not the 

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 



Other related posts: