Thanx Mark, Before i get to clarifying what my last question in the prev mail was about, i have another doubt. I was reading thru the server architecture document and came accross the Shadow FB Engine. "The Shadow FB engines use Keith Packard's FB drawing procedures wrapped with his Shadow layer that allows drawing to an offscreen framebuffer with periodic updates of the primary framebuffer." What i understood by this is, i can create a copy of the framebuffer in the memory(possibly save it to the hard drive) and use it like a windows bitmap. This bitmap will have the image of the screen(Eg: a linux desktop equivalent to a windows desktop snapshot). What i meant by my last question was: If my preveious inference is correct, then can i use this Shadow Engine, or write an engine of my own that would capture the graphic information of only the active window(top level window) of the screen. What i am looking to do is, open an appication and only capture the graphics related to the window the application opens. Thanks, Preetham.
Mark Vojkovich wrote: >On Thu, 18 Jul 2002, Preetham wrote: > >>> Be careful. A "Display" in X-Window terminology is a connection to >>>the X-server. A single client can open many "Display" connections all >>>to the same screen. It's a "screen" that indicates a framebuffer. >>> >>Correct me if i am wrong: >> > > You are wrong. > >>1.What you mean to say is: >>Display is a connection to a screen, and all clients that share the display, >>write graphics >>information to the same screen. >> > > A "Display" in Xlib is a connection to a server. A Display is >exclusive to a client. A client can use that Display to render to >any Screen on the X-Server. A "Display" is an opaque handle within >the client's namespace. Actually, my comment about a single client >opening many Display connections was inaccurate. What I meant to >say was that a process may open as many Display connections as it >wants. Each Display connection is essentially a different client >and the X-server has no way of knowing that two particular clients >are really the same process. Basically, client == Display connection. >An app that opens a Display and uses a toolkit that also opens a >display is actually two clients. The X-server does not know that >they are the same application. > > >>2. So, each X-Server can have only one framebuffer. >> > > Each X-server can have as many framebuffers (screens) as it wants. >The #define limit in XFree86 is 32, but only 16 have been tested. >There is one special case (Xinerama) where multiple framebuffers are >used to make up one screen from the client's point of view. > >>3.If i create a seperate buffer(one for each client, not a consolidated >>screen), >>is it possible to modify the XServer to capture the graphics generated by >>each >>of the clients and write them into their corresponding buffers. >> > > I don't understand what you have described there. There is >only one framebuffer per screen. The concept of a separate buffer >per client doesn't make sense. While particular operations are >associated with a client some are not. Painting of a window background >for instance may be instigated by movement of another window without >any action initiating it by the client who created painted window. Also, >a client can render into a window it didn't create. Any drawable, >regardless of who created it is fair game for any client. And the >root window isn't owned by any client - it is owned by the X-server. > > Perhaps if you would explain what it is that you are trying to >do. > > > Mark. > _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
