On Mon, May 4, 2009 at 5:48 PM, Darin Fisher <da...@chromium.org> wrote:
> On Mon, May 4, 2009 at 1:08 AM, Dean McNamee <de...@chromium.org> wrote:
>>
>> On Mon, May 4, 2009 at 12:15 AM, Darin Fisher <da...@chromium.org> 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.
Sorry, I am not too familiar with this code, so I'm probably a bit
lost. Are you talking about windowed or windowless plugins? You said
reposition, so I am assuming you are talking about windowed plugins.
In that case I completely don't understand what you just said :)
Thanks
> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
