DirectFB - Home of the pragmatist Roadmap


[directfb-dev] Re: blanking of non-refreshing windows
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-dev] Re: blanking of non-refreshing windows


  • To: Michel Dänzer <michel@daenzer.net>
  • Subject: [directfb-dev] Re: blanking of non-refreshing windows
  • From: Denis Oliver Kropp <dok@directfb.org>
  • Date: Tue, 9 Sep 2003 18:07:35 +0200
  • Cc: devel@xfree86.org, directfb-dev@directfb.org
  • Content-disposition: inline
  • Content-transfer-encoding: 8bit
  • Content-type: text/plain; charset=iso-8859-1
  • In-reply-to: <1061504077.1862.64.camel@thor.holligenstrasse29.lan>
  • References: <20030812094910.A1963@hexapodia.org> <1060767547.26450.132.camel@thor.holligenstrasse29.lan> <20030813092952.A6553@hexapodia.org> <1060941977.27494.269.camel@thor.holligenstrasse29.lan> <20030821161238.A546@hexapodia.org> <1061504077.1862.64.camel@thor.holligenstrasse29.lan>
  • Reply-to: Denis Oliver Kropp <dok@directfb.org>
  • Sender: directfb-dev-bounce@directfb.org
  • User-agent: Mutt/1.5.4i

Quoting Michel Dänzer (michel@daenzer.net):
> On Thu, 2003-08-21 at 23:12, Andy Isaacson wrote:
> > On Fri, Aug 15, 2003 at 12:06:18PM +0200, Michel Dänzer wrote:
> > > On Wed, 2003-08-13 at 16:29, Andy Isaacson wrote:
> > > > I'm not familiar with how those two X servers operate, so could you help
> > > > me out by explaining?  How do they handle window obscures?  How is it
> > > > different from X11's BackingStore?
> > > 
> > > I don't know a lot of details yet, but they indeed always keep the
> > > contents of windows around and composite the desktop with them
> > > (actually, they have another windowing system do this, but that's not
> > > the point).
> > 
> > Seems to me you've got to break X11 semantics in order to do this:  I
> > suppose they must disable PartiallyObscured events, otherwise the
> > "hidden" portion of the app windows won't get updated.

Right, in XDirectFB overlapping top level windows don't obscure or expose
each other. Each top level window has its own surface in (video) memory.
After a bunch of updates done by the application, the screen region affected
by these changes is recomposed by blitting the window surfaces to the
layer's surface (screen). Alpha blended windows are blitted via TMU, at
least with a Matrox. In other words, we already had windows being a texture
three years ago, Longhorn has it now.

> (Personally, I'd consider even outdated window contents more useful than
> unrelated contents or none at all until the client handles the expose
> event?)

There's no old content. Applications still draw to regions that are not visible
to the user (yet).

> > > > too often the BS pixmap is too old, and the X server writes it to the 
> > > > framebuffer only to have it overwritten by the app as soon as it's 
> > > > scheduled.
> > > 
> > > Well, do you want the windows to be refreshed ASAP or not? :) I don't
> > > think this is a big deal as the windows will be kept in video RAM
> > > whenever possible.
> > 
> > I want the window contents to be correct, or at least, innocuous.  I
> > agree that if the backing store is kept in the off-screen framebuffer
> > the overhead is minimal; I don't think XFree86's BS implementation can
> > do that.  
> 
> Right. I haven't noticed much difference in general with my every day
> apps, except that XDirectFB looks and feels snappier and smoother.

That's because a) there are much less expose events an b) each single
drawing operation is not immediately visible to the user. Therefor a
clear plus some drawing appears at once. But it depends on the interactivity
of the server and the client. It flickers rarely.

> > In general I want the system to work correctly an in a performant 
> > manner even if the number of windows exceeds available off-screen 
> > framebuffer memory.
> 
> It would be interesting how it performs in that case indeed; I don't
> expect it to be too bad though as it was quite usable even without any
> hardware acceleration.

The surface manager of DirectFB kicks out older window surfaces if
no free space is available. Only if many windows overlap while
being transparent, it could slow down noticably, because all windows
are needed to recompose the stack. But with a 32MB card I have space
for many windows ;)

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH


-- 
Info:  To unsubscribe send a mail to ecartis@directfb.org with 
"unsubscribe directfb-dev" as subject.



Home | Main Index | Thread Index


directfb.org / Development / Old Archives