[haiku-appserver] Re: BWindowScreen results /app_server fault

  • From: "Rudolf" <drivers.be-hold@xxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 04 May 2006 16:20:19 +0200 CEST

Hi,

Hmm, I am now compiling with thisabled memcpy() back into the 
framebuffer upon REsume() execution in BWindowSCreen. What's this meant 
for?
(Just curious..)

Rudolf.





> Hi guys,
> 
> Well, I got another update. Just ran the latest build with Axel's 
> invalidate fix for overlay, and also tested WindowScreen again.
> 
> So, All in all it seems the app_server doesn't draw: I saw partially 
> updated Terminal window during running a BWindowScreen app before, 
> but 
> now I don't see that at all. Also, no rubbish is visible after 
> starting 
> BWindowScreen (was app server as well I think), instead the screen is 
> cleared.
> 
> My test app runs perfectly now, the gfxbusbench app runs perfectly as 
> well. Also the screen is nicely restored always at the end of 
> BWindowScreen use.
> Still, page_flipper has a fault:
> OK is:
> -screen cleared (no rubbish) at start.
> -Curled white lines are momentarily visible, so that works after all
> -ball is displayed
> -curled while lines background (presumably sitting in the part of gfx 
> mem where normally the app_Server draws(?)) are cleared to black. OR 
> is 
> this the BWindowScreen implementation's doing?
> -ball nicely rolls over the screen, on a black background instead of 
> those curled white lines,
> -after app quit: desktop perfectly restored.
> 
> 
> Well, there is a fault still therem in the app_server or the 
> BWindowScreen class: the screen drawn black isn't meant to be: maybe 
> it's issued "to late" or, multiple times,of which one is after the 
> app 
> drawing into the 'workspace'. Hope one of you sees what's going 
> wrong, 
> I don't know ATM.
> 
> 
> --------
> 
> About overlay: (axel)
> CPU load remains (About) the same, so this isn't the primary fault. 
> However, I _did_ notice this time around that the fact VLC is running 
> increases CPU load: and it looks like we have the diff (most of it) 
> sitting in _this_ fact: on dano CPU load isn't noticely increased 
> when 
> VLC is idle (no media file loaded yet). On haiku you see the green 
> thing being drawn over and over (indicating where we are in a media 
> file), while on R5 it's not even visible.
> 
> So, it seems (unless I did not test good enough yet), that app_server 
> behaves a bit differently with this' widget' or what you call it 
> (newby 
> here :), and on top of that, VLC running idly consumes too much CPU.
> 
> 
> That's about it for now. Maybe I'll tweak a bit more with 
> WindowScreen 
> to see if I can find an additional pointer to the deleting of the 
> while 
> curly lines.. If I find anything I'll let you know.
> 
> 
> Thanks for your time! (and sorry if I cause any inconveniance: that's 
> not my intention).
> 
> Bye!
> 
> Rudolf.
> 
> > Hi,
> > 
> > > >app_server draws in the screen! This of course is >
> > > > prohibited....
> > > >This probably also solves the curved white lines >error once 
> > > > solved.
> > > 
> > > This is probably what the kWindowScreenSpecialFlag is for. In R5, 
> > > I 
> > > remember those curved white lines weren't shown till I added that 
> > > flag to 
> > > the BWindowScreen constructor. So we need to handle that flag in 
> > > the app 
> > > server.
> > 
> > I don't understand. In what situation does the server draw on the 
> > screen 
> > when it should not?
> > 
> > Best regards,
> > -Stephan
> > 
> > 
> > 
> 
> 
> 


Other related posts: