On Mon, May 4, 2009 at 1:08 AM, Dean McNamee <[email protected]> wrote:
> On Mon, May 4, 2009 at 12:15 AM, Darin Fisher <[email protected]> wrote: > > Painting is not the only issue. On Windows there are several ways in > which > > the thread responsible for a HWND can block waiting for the thread > > responsible for a child HWND to respond. Are you sure there are no X > calls > > that block in a similar fashion? Are there no cases where you can query > > something about a child X window that would require asking the "client" > > associated with that X window to provide some data? > > One nice thing about X and the client/server model, is that there is a > clear interface > and description of what can happen. I don't think X ever "asks" an > application for > information, instead the application always tells X things, and X > maintains the state. > > Therefore I can't imagine anything happening in X like this: > > App1 -> request -> X -> request App2 > > That is because X does not have a mechanism to ask things from the > client, only to > notify it about events. That said, we're using Xembed for plugins, > and I don't know exactly what it involves. I would still be surprised > to see this situation arise however. > > To quote some X tutorial: http://www.visi.com/~grante/Xtut/ > > As stated earlier, the X protocol defines what passes back and forth > between the client and the server. The information that travels > between client and server is broken up into ``packets'' at the X > protocol level (which is different than Ethernet or TCP/IP packets or > frames). There are four types of packets: > > - Request > A request packet is sent by the client to the server to ask that the > server perform some action or return some information. > > - Reply > A reply packet is sent by the server to the client in response to a > request from the server. Not all requests generate replies. > > - Event > An event packet is sent by the server to the client to inform it of > user input or some other happening about which it might want to do > something (for example a window was re-sized or a previously obscured > window was uncovered). > > - Error > An error packet is sent by the server to the client to inform it that > a request was not valid. Since requests are queued, the error might > not be discovered until after several more requests have been queued > by the client. > Good to know. However, this morning it occurred to me that it almost doesn't matter. Consider the case of scrolling a page with plugins: To scroll the page so that it looks like everything is scrolling as one piece, we have to blit the backingstore to the screen for the render view, and then we need to re-position and possibly re-paint any exposed plugin windows. We need to make all of this happen together, which on Windows is accomplished by synchronizing the browser UI thread with the plugin UI thread. So, I don't believe that we can avoid the need to block the browser UI thread on the plugin UI thread. -Darin --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
