Quoting Michel Dänzer ([EMAIL PROTECTED]): > 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 _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
