
|
[haiku-appserver]
||
[Date Prev]
[05-2006 Date Index]
[Date Next]
||
[Thread Prev]
[05-2006 Thread Index]
[Thread Next]
[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
> >
> >
> >
>
>
>
|

|