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
The Mac needs something morally equivalent to #2 (with plugins as the
current forcing function--there's no cross-process window handle we
can use, so we need to track them ourselves anyway). I also strongly
agree that the browser needs to be able to validate which window(s) a
renderer can ask
The only thing I can thing of that involves a
client-server-client-server-client world tour in X is selection
handling, but that's asynchronous. Querying window properties only
looks at server state (also true for the Mac's window server--there's
no such thing as a synchronous call from the
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
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
On Mon, May 4, 2009 at 9:01 AM, Dean McNamee de...@chromium.org wrote:
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:
On Fri, May 1, 2009 at 1:46 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote:
On Fri, May 1, 2009 at 1:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, May 1, 2009 at 1:27 PM, Adam Langley a...@chromium.org wrote:
On Fri, May 1, 2009 at 12:53 PM, Jeremy Orlow jor...@google.com wrote:
Re-sending. Wrong address the first time.
I see. In this design, we would translate render_view_ids to
NativeViewIds on the IO thread instead of round-tripping the UI
thread. That seems workable without changing the semantics of the IPC
messages.
Adam
On Sun, May 3, 2009 at 10:31 PM,
Is this implemented on the Mac? This seems like a mapping from
NativeViewId to whatever the Mac version of an HWND is, which sounds
similar to gtk_native_view_id_manager...
Adam
On Mon, May 4, 2009 at 5:55 AM, Amanda Walker ama...@chromium.org wrote:
The Mac needs something morally
It's not implemented yet--I spent some time trying to get mac plugins
working without a real window, without success, and have recently
fallen back to creating an offscreen window for the plugin's use. My
current plan once the plugin-related IPC code is working on the Mac is
to refactor a
Yes, seems like it should be all around cleaner too :)-Darin
On Mon, May 4, 2009 at 9:43 AM, Adam Barth aba...@google.com wrote:
I see. In this design, we would translate render_view_ids to
NativeViewIds on the IO thread instead of round-tripping the UI
thread. That seems workable without
2009/5/4 Darin Fisher da...@chromium.org:
Maybe we can reuse MakeTuple and DispatchToFunction from base/tuple.h ?
-Darin
I started looking at this, but it ends up being a fair amount of
template magic to deal with a situation which hasn't ever actually
happened in the code (even without the
On Mon, May 4, 2009 at 11:06 AM, Adam Langley a...@chromium.org wrote:
2009/5/4 Darin Fisher da...@chromium.org:
Maybe we can reuse MakeTuple and DispatchToFunction from base/tuple.h ?
-Darin
I started looking at this, but it ends up being a fair amount of
template magic to deal with a
On svn, it's not integrated yet. Roughly:
curl http://...patchset.diff | patch -p0
# need to fix that:
echo change id ./.svn/gcl_info/temp_change
gcl try temp_change
gcl commit temp_change
The issue with that at the moment is that a @chromium.org user cannot use
/close POST url (used by gcl on
After a conversation in the multi-platform meeting today it was decided to
deprecate the mstone:mac and mstone:linux labels in issue tracker in favor
of mstone:MacDev and mstone:MacBeta and the corresponding Linux labels.
This will allow the team to differentiate between issues required for the
Hmm. Would it be even cleaner for nothing but the plugin host process
to care about the NativeViewId, since it's what has to provide it to
the plugin via NPAPI? For everything else, either we're windowless
and just shipping bitmaps around (no need for a window reference at
all except to keep
Right, that's actually what I'm suggesting we aim for. When the renderer
needs to ask questions about the HWND associated with a RenderView, it can
just ask questions of the RenderViewHost. The RenderViewHost can use its
HWND to answer the questions.
The story is not quite that simple of course
Got it. Sounds good from my end.
--Amanda
On Mon, May 4, 2009 at 5:08 PM, Darin Fisher da...@chromium.org wrote:
Right, that's actually what I'm suggesting we aim for. When the renderer
needs to ask questions about the HWND associated with a RenderView, it can
just ask questions of the
I created a new toplevel app directory, and moved ResourceBundle
into it. Some of the bots look happy enough with this but in my
experience sometimes my local Visual Studio isn't. So if you see any
link errors relating to ResourceBundle, clobber the affected projects
and common.
-Ben
19 matches
Mail list logo
