summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_widget.h
Commit message (Collapse)AuthorAgeFilesLines
* When the plugin crashes, cleanup references to its window in the renderer.piman@chromium.org2009-08-061-1/+6
| | | | | | | | | This avoids spurious messages when the plugin crashes, and potential issues (plugin crashes, the HWND/XID gets destroyed, a new one gets created by a new instance and gets the same HWND/XID, the browser operates on the new one instead of the old one). Review URL: http://codereview.chromium.org/160614 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22688 0039d316-1c4b-4281-b951-d872f2087c98
* Split the IPC code into ipc/agl@chromium.org2009-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This splits the ipc code from the common project. The 'common' project pulls in all of webkit, the v8 bindings, skia, googleurl, and a number of other projects which makes it very difficult to deal with especially for external projects wanting just to use some of Chromium's infrastructure. This puts the ipc code into its top-level ipc/ directory with a dependency only on base. The common project depends on the new ipc/ipc.gyp:ipc target so that all projects currently pulling common in to get the IPC code still have it available. This mostly follows agl's pre-gyp attempt to do this which was r13062. Known issues: - Currently a number of projects depend on chrome/chrome.gyp:common in order to use the IPC infrastructure. Rather than fixing all of these dependencies I have made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules section of DEPS so that checkdeps.py doesn't complain. Over time projects that need IPC should depend on the IPC project themselves and dependencies on common removed, although I don't think many projects that need IPC will be able to get away without common currently. - ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve this since it's really an IDE bug - the named pipe name (windows+linux) and the logging event name (all) + env variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion of ipc/ being an independent library. I think this should be examined in a subsequent, much smaller patch. - I've eliminated the IPC.SendMsgCount counter since it was implemented in a way to create a dependency from ipc/ to chrome/common/chrome_counters. This is the same approach that r13062 took. http://codereview.chromium.org/155905 (Patch from James Robinson) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 20855.darin@chromium.org2009-07-161-29/+28
| | | | | | Review URL: http://codereview.chromium.org/149744 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20859 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 20854.darin@chromium.org2009-07-161-28/+29
| | | | | | Review URL: http://codereview.chromium.org/155621 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20855 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebWidget from the WebKit API. This change also makesdarin@chromium.org2009-07-161-29/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use of WebKitClient (replacing WebWidgetDelegate from glue). The ripple effects of this change are rather large, but most of the impact is mechanical. The more interesting changes include: 1- Removing the WebWidget parameter from WebWidgetClient methods. This didn't matter at all to RenderWidget or RenderView, but it did cause some changes to be made to TestWebViewDelegate. Now, it is not possible to share a delegate implementation for both the WebView and a popup menu, so I have a second instance of the delegate owned by TestShell for use with popup menus. 2- Plumbing WebNavigationPolicy in place of WindowOpenDisposition was getting to be a pretty large change, so I stopped short of deleting WindowOpenDisposition. That way the Chrome side can remain mostly unmodified. I then added a mapping function to convert from WebNavigationPolicy to WindowOpenDisposition. 3- The IME methods on WebWidget were renamed (reviewed separately by hbono), and there is now an enum to specify the composition command (WebCompositionCommand). 4- I added IPC serialization for WebCompositionCommand and WebTextDirection, which cleaned up some code that was just using ints in IPC messages. R=jam BUG=16234 TEST=none Review URL: http://codereview.chromium.org/149620 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20854 0039d316-1c4b-4281-b951-d872f2087c98
* Replace ShowAsPopupWithItems to CreatePopupWidgetWithInfo. Also,darin@chromium.org2009-07-141-5/+12
| | | | | | | | | | | | | | | | | | make use of WebPopupMenuInfo from the WebKit API. WebMenuItem remains in webkit/glue for convenience with IPC marshalling and related usage in Chrome. This work is precursor to switching over to using WebWidget from the WebKit API. BUG=16234 TEST=html select drop downs should still work on the mac. try switching languages on news.google.com. R=paul Review URL: http://codereview.chromium.org/155378 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20624 0039d316-1c4b-4281-b951-d872f2087c98
* Remove reference counting from WebWidgetDelegate.darin@chromium.org2009-07-091-8/+0
| | | | | | | | | | | | | | | | | This was added as a speculative crash fix by eseidel back in June of 2008. See http://b/1211911 for details. It didn't appear to resolve the crash then (as another patch was required to fix the bug), and it doesn't seem to be necessary since the RenderView, which is the delegate and owns the WebView, is the one in charge of allocating the WebView and destroying the WebView. So, it is not possible for the WebView to outlive the RenderView. BUG=16234 TEST=none R=brettw Review URL: http://codereview.chromium.org/155292 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20294 0039d316-1c4b-4281-b951-d872f2087c98
* Remove WebWidgetDelegate::GetContainingView since it is not needed.darin@chromium.org2009-07-091-1/+0
| | | | | | | | | | TEST=none BUG=16234 R=jam Review URL: http://codereview.chromium.org/155243 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20213 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebCursorInfo from the WebKit API. WebCursorInfo is adarin@google.com2009-07-081-1/+2
| | | | | | | | | | | | | | | | lightweight struct containing a description of a cursor that the embedder should render. WebCursor still exists. Instead of WebCursor initializing from a PlatformCursor, it now initializes from a WebCursorInfo. TEST=none BUG=10039 R=jam Review URL: http://codereview.chromium.org/155172 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20194 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for reverted cl http://codereview.chromium.org/147123davemoore@chromium.org2009-06-271-0/+4
| | | | | | | | | | | | | A recent change broke the load times. It also revealed some deficiencies. This adds a new time marker for when a load is committed, which is a more interesting value than the start of the load (which we still keep). Also, the first layout time wasn't an interesting time to keep, instead we keep the time of the first paint. The histograms were modified to use the new values when appropriate. Review URL: http://codereview.chromium.org/149099 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19465 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 19361.davemoore@chromium.org2009-06-261-4/+0
| | | | | | | tbr=darin Review URL: http://codereview.chromium.org/149081 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19368 0039d316-1c4b-4281-b951-d872f2087c98
* A recent change broke the load times. It also revealed some deficiencies.davemoore@chromium.org2009-06-261-0/+4
| | | | | | | | | | | | This adds a new time marker for when a load is committed, which is a more interesting value than the start of the load (which we still keep). Also, the first layout time wasn't an interesting time to keep, instead we keep the time of the first paint. The histograms were modified to use the new values when appropriate. Review URL: http://codereview.chromium.org/147123 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19361 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 18765 to try to repair perf regressionjar@chromium.org2009-06-191-1/+1
| | | | | | | TBR=mpcomplete Review URL: http://codereview.chromium.org/131093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18784 0039d316-1c4b-4281-b951-d872f2087c98
* Send port-closed notification when a frame with ports unloads.mpcomplete@google.com2009-06-181-1/+1
| | | | | | | | | | | | | Also add onLoad and onUnload chrome Event to our bindings, so we can add listeners to these events without needing a DOM. These don't hook into the window "unload" event, so we no longer prevent Chrome's sudden termination of tabs on shutdown. BUG=12686 TEST=no Review URL: http://codereview.chromium.org/125280 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18765 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting Rev 18383 since it brings down the performance of single core page ↵mad@chromium.org2009-06-151-4/+1
| | | | | | cyclers too much... git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18385 0039d316-1c4b-4281-b951-d872f2087c98
* This is to thest the page cycler performance without the resize corner, to ↵mad@chromium.org2009-06-151-1/+4
| | | | | | | | | | | | | see if these paint optimizations are worth it. I will revert these changes as needed... You may revert them yourself if they cause you trouble before I get to revert them. I have tested these changes on two different linux configuration, but there are more code paths that I couldn't verify myself, though agl gave me the OK anyway. These changes have already been reviewed here: http://codereview.chromium.org/108040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18383 0039d316-1c4b-4281-b951-d872f2087c98
* Revert mad's backing store changes, it completely hosed Linux painting.deanm@chromium.org2009-06-111-4/+1
| | | | | | | | | This was r18090, reverted in r18092, recommitted without review in 18130. Review URL: http://codereview.chromium.org/122034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18158 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding reverted patch 18090.mad@google.com2009-06-111-1/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18130 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 18090jrg@chromium.org2009-06-101-4/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18092 0039d316-1c4b-4281-b951-d872f2087c98
* To help resolve the performance issue introduced when enabling the resize ↵mad@google.com2009-06-101-1/+4
| | | | | | | | corner, we now keep all non-intersecting rects separately and send an array of invalidation bitmaps via IPC as opposed to a single unionized rect :-) Review URL: http://codereview.chromium.org/108040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18090 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes a flash plugin hang caused by opening google finance ticker symbols in ↵ananta@chromium.org2009-06-091-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a background tab. From what I can tell this bug always existed in Chrome. The flash plugin gets instantiated and gets initial geometry updates during initialization. We download the plugin url after the geometry update. After these geometry updates the webkit layout timer runs and the plugin gets additional geometry updates. However these don't get sent over to the flash plugin instance in the plugin process as the geometry updates for windowed plugins are only flushed during paint, which does not happen in this case. The flash plugin ends up receiving data before geometry update and ends up behaving in a wierd fashion, i.e. not peeking for messages, etc. The fact that this is a windowed plugin results in the browser ui thread also getting hung until the plugin gets out of this state. The fix for the geometry update issue is to remove the deferred geometry update stuff. This only exists for windowed plugins anyway. The geometry update IPC is a plain routed message and it should not be a big overhead to send these IPCs to the plugin process. I found that while this change fixes the basic issue, we still see some hangs in the flash plugin because of it receiving data before the valid geometry update kicks in. John is working on a fix where we never have to call setFrameRect ourselves and always honor the setFrameRect calls made by Webkit. This issue can be marked as fixed once both fixes get checked in. This fixes http://code.google.com/p/chromium/issues/detail?id=12993 Bug=12993 TEST=Open google finance and Ctrl Click on the tickers in the page like Basic Materials, etc. Review URL: http://codereview.chromium.org/119200 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17918 0039d316-1c4b-4281-b951-d872f2087c98
* This CL updates chrome to the latest version of skia, retrieved via DEPS, andsenorblanco@chromium.org2009-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | placed in third_party. All relevant skia changes (for all 3 platforms) have been upstreamed. Most of this CL is mind-numbingly repetitive. Things of interest are: skia.gyp (now points at third_party versions), DEPS, and SkUserConfig.h. stdint.h: Skia now requires C99 integer types, which MSVC doesn't support natively. I have put typedefs in config/win/stdint.h. Note that the new version of skia appears to render rects whose coordinates are "backwards" (ie., x2 < x1 or y2 < y1), which were formerly culled. There were a couple obvious instances of this in the code which I fixed, but there may be more. There were ~35 layout test failures due to minor pixel differences which I rebaselined on Windows and Linux, and 8 genuine failures related to masks and stroked text, which I have put in text_expectations.txt and assigned to myself. (There was another change which broke ~1700 tests on each platform, but I put that change behind an #ifdef for now). R=brettw Review URL: http://codereview.chromium.org/65012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15949 0039d316-1c4b-4281-b951-d872f2087c98
* Move WebKit API to src/webkit/api.darin@chromium.org2009-05-101-1/+1
| | | | | | | | R=dglazkov Review URL: http://codereview.chromium.org/113186 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15739 0039d316-1c4b-4281-b951-d872f2087c98
* Defer window.close(), resizeTo() and moveTo() actionsmbelshe@google.com2009-05-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | by posting a task back to the message loop before notifying the RenderWidgetHost to perform these operations. Otherwise the JS code races with the browser to use the modified window. BUG=http://crbug.com/6377 BUG=http://crbug.com/6192 Cache a pending_window_rect on the render_view (moved from prior CL where I had it on the chrome_client_impl). This is a short lived cache, and not a complete solution. It fixes this case, where a JS script makes multiple operations and expects the GetWindowSize() to be correct immedately after having called SetWindowSize(). BUG=http://crbug.com/835 Review URL: http://codereview.chromium.org/115030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15698 0039d316-1c4b-4281-b951-d872f2087c98
* Revert bug fix because interactive_ui_tests are failing.mbelshe@google.com2009-05-041-6/+0
| | | | | | Review URL: http://codereview.chromium.org/99358 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15227 0039d316-1c4b-4281-b951-d872f2087c98
* Defer window.close(), window.resizeTo(), and window.moveTo()mbelshe@google.com2009-05-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | actions by posting a task back to the message loop before notifying the RenderWidgetHost to perform these operations. Otherwise, the JS code races with the browser to use the modified window. BUG=http://crbug.com/6377 BUG=http://crbug.com/6192 Also, because window resizing is asynchronous between the renderer and browser, added a renderer-side cache of "pending window rect" to ChromeClientImpl. Before the change, calling setWindowRect() would schedule a call to the RenderViewHost to do the work, but a subsequent call to windowRect() would return the current size, as through the call to setWindowRect() had never happened. We cache a pending size and then schedule a task on the message loop to clear the cached size. This allows javascript which writes and reads the WindowRect sizes to work, and once we come out of JS and return to the message loop, we'll go back to asking the RenderViewHost for the true values. This pending_window_size is my only concern about this patch. It does pass all layout tests, and the ChromeClientImpl code is executed in the test_shell.exe code path. BUG=http://crbug.com/835 TEST=LayoutTests have tests which cover all of these actions. The problem is that we run layout tests using the test_shell, not Chrome. Review URL: http://codereview.chromium.org/101019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15214 0039d316-1c4b-4281-b951-d872f2087c98
* Add transparency support to RenderWidgetHostView.aa@chromium.org2009-04-231-0/+9
| | | | | | | | | | | | This is used to make the background behind toolstrips 'shine through' them. It isn't possible to make them really transparent due to cleartype (cleartype must know the pixels behind the text to work), so instead we paint the background we want behind the transparent webview. Review URL: http://codereview.chromium.org/88076 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14378 0039d316-1c4b-4281-b951-d872f2087c98
* DevTools: Run nested message loop instead of whitelisting the messages.pfeldman@chromium.org2009-04-221-0/+3
| | | | | | Review URL: http://codereview.chromium.org/90007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14183 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome side of the WebKit popup changes.paulg@google.com2009-04-101-6/+6
| | | | | | | | | | | Implements HTML select popups on Mac OS X as native Cocoa controls. BUG=5095 (http://crbug.com/5095) Review URL: http://codereview.chromium.org/67018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13495 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-091-7/+10
| | | | | | | | | | | | | | | | | layer interface. This will help when we move those interfaces into the WebKit API. This is a second attempt at r13381, which was already reviewed here: http://codereview.chromium.org/63126 The only change between that CL and this one is in render_view.h, where I needed to change a parameter type from gfx::Rect to WebRect. TBR=dglazkov Review URL: http://codereview.chromium.org/64005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13424 0039d316-1c4b-4281-b951-d872f2087c98
* When the Find bar has focus it eats keypresses such as PageUp, PageDown and ↵finnur@chromium.org2009-04-081-5/+5
| | | | | | | | | | | | | | | Up and Down arrow keys. It doesn't need to - instead the page should scroll even if focus is on the Find bar. This patch forwards those selected keypresses to the page for its perusal. Known issues: Just like Firefox, the page doesn't scroll if it has frames. SONG=I like to fixit fixit. I like to fixit fixit. BUG=7079 TEST=Open FindInPage on a webpage that has a vertical scrollbar. Press Down, Up, PageDown and PageUp and the page should scroll accordingly. Make sure no ding is heard while doing so. Also make sure this works if focus is on a textfield/textarea when you press Ctrl+F. Review URL: http://codereview.chromium.org/62129 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13389 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting dfisher changes 133386 and 13381cpu@google.com2009-04-081-10/+7
| | | | | | | | | | TBR=darin Review URL: http://codereview.chromium.org/58018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13387 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-081-7/+10
| | | | | | | | | | | layer interface. This will help when we move those interfaces into the WebKit API. R=dglazkov Review URL: http://codereview.chromium.org/63126 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13381 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Move IPC code to ipc/"agl@chromium.org2009-04-031-1/+1
| | | | | | | This reverts commit r13062 which, unsurprisingly, broke the build. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13063 0039d316-1c4b-4281-b951-d872f2087c98
* Move IPC code to ipc/agl@chromium.org2009-04-031-1/+1
| | | | | | | (No review URL: Rietvelt couldn't cope) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13062 0039d316-1c4b-4281-b951-d872f2087c98
* Replace webkit/glue/screen_info.h with WebKit/chromium/public/WebScreenInfo.hdarin@chromium.org2009-04-011-6/+7
| | | | | | | | | | | | | This also eliminates webkit_glue::GetScreenInfo and webkit_glue::GetScreenInfoHelper. As part of this CL, I also extracted all of the ParamTraits for WebKit API types into chrome/common/webkit_param_traits.h. R=dglazkov Review URL: http://codereview.chromium.org/58008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12993 0039d316-1c4b-4281-b951-d872f2087c98
* A tricky fix for Issue 1845 (Take 2).hbono@chromium.org2009-03-251-0/+1
| | | | | | | | | | This is almost the same change as <http://codereview.chromium.org/39252/show>, which caused a build break on a Linux buildbot while compiling my new template function in "chrome/common/render_messages.h". Even though I was not able to reproduce the build errors on my Linux box, I removed this function and use the int type in my IPC message 'ViewMsg_SetTextDirection'. BUG=1845 Review URL: http://codereview.chromium.org/42495 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12434 0039d316-1c4b-4281-b951-d872f2087c98
* First stage of implementing HTML select popup menus forpaulg@google.com2009-03-241-0/+5
| | | | | | | | | | | | | | | | the Mac test_shell. Once the changes to WebKit/WebCore/platform/chromium/PopupMenuChromium* have been upstreamed (then landed in our tree), we can enable them in test_shell. The WebKit part is contained in this bug: https://bugs.webkit.org/show_bug.cgi?id=24692 BUG=5095 (http://crbug.com/5095) Review URL: http://codereview.chromium.org/48149 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12382 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 11953.hbono@chromium.org2009-03-181-2/+0
| | | | | | Review URL: http://codereview.chromium.org/48121 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11954 0039d316-1c4b-4281-b951-d872f2087c98
* A tricky fix for Issue 1845.hbono@chromium.org2009-03-181-0/+2
| | | | | | | | | | | | | | | | | This change is a very tricky fix for Issue 1845 in chromium: cant alignt text to the right using right shift and right ctrl.This change consists of two parts listed below. 1. Emulating the implementation of Safari that changes the text-direction of an input element. Safari uses context menus to change the text direction. This change adds an IPC message 'ViewMsg_SetTextDirection', which notifies the new text direction. Also, it adds two functions: RenderWidgetHost::UpdateTextDirection() and RenderWidgetHost::NotifyTextDirection(). They encapsulate the new IPC message so that we can use them both when we presses a set of keys and when we add context-menu items which change the text direction. 2. Calling the above interface when pressing right-shift and right-control keys, or when left-shift and left-control keys. This modifies the RenderWidgetHostViewWin::OnKeyEvent() function and call the above text-direction interfaces when a user finishes pressing the keys. As you can imagine, if we send an IPC message every time when we receive a WM_KEYDOWN event, we continue sending IPC messages while a user is pressing the keys. BUG=1845 Review URL: http://codereview.chromium.org/39252 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11953 0039d316-1c4b-4281-b951-d872f2087c98
* This CL causes the autofill popup to hide when the browser window is moved ↵jcampan@chromium.org2009-02-251-1/+2
| | | | | | | | | | | or resized. TEST=Bring up an autofill popup in a form, move the browser. The autofill popup should be closed. BUG=7401 R=ben Review URL: http://codereview.chromium.org/28126 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10384 0039d316-1c4b-4281-b951-d872f2087c98
* Keeping track of whether WebKit is in the callstack using RenderThread ↵jam@chromium.org2009-02-241-3/+0
| | | | | | | | | | | | doesn't work when there are Send calls to plugins (i.e. Gears). So instead, just use PostNonNestableTask to delete RenderWidget. I (Note I still don't know how my change affected this, it seems to have been broken before as well.) BUG=7951 Review URL: http://codereview.chromium.org/28090 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10298 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-211-1/+1
| | | | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=10080 Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10144 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 10080.jam@chromium.org2009-02-201-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10082 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-201-1/+1
| | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10080 0039d316-1c4b-4281-b951-d872f2087c98
* Bitmap transportagl@chromium.org2009-02-201-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch reworks bitmap transport on all platforms. Linux and Mac are switched from serialising bitmaps over the IPC channel to using shared memory. All platforms gain a shared memory mapping cache on the host side. The concept of a TransportDIB (device independent bitmap) is added to encapsulate most of the platform specifics. On Linux, we use SysV shared memory. This is because X shared pixmaps, which predate POSIX SHM, can only use SysV. By using SysV between renderer and browser, we open up the possibility to map the shared memory directly from the renderer to the X server. On Mac, we use POSIX shared memory. However, since this needs filesystem access and the Mac renderer is sandboxed from the filesystem, we add two new messages from renderer -> browser: The first, AllocTransportDIB, synchronously creates a transport DIB in the browser and passes a handle back to the renderer. The second, FreeTransportDIB, asynchronously, notifies the browser that it may close its handle to the shared memory region. On Mac, the shared memory regions are identified by their inode numbers on the wire. This means that the browser must keep handles open to all the allocated shared memory regions (since an inode number is insufficient to map the region). The alternative design is that the renderer passes the file descriptor with each paint operation. Since passing file descriptors is special case in the code, I felt that it would be best to minimise their use. Creating and freeing transport DIBs are relatively rare operations relative to paints and scrolls. On Windows, most of the code remains the same, except that Windows now uses the mapping cache added in this patch. This allows the browser to maintain a shared memory mapping for a transport DIB over several paints. Previously it mapped and unmapped for every operation, causing lots of TLB and VM churn. Review URL: http://codereview.chromium.org/21485 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10071 0039d316-1c4b-4281-b951-d872f2087c98
* The WebFrame interface currently supports reference counting, but no one uses.darin@chromium.org2009-02-131-1/+2
| | | | | | | | | | | | | | | | Internally, WebFrameImpl needs reference counting, so we still define it there. Same goes for WebView and WebWidget. While making this change, I noticed that WebInspectorClient was casting WebView pointers to WebViewImpl pointers too much. By just starting with WebViewImpl pointers, things could be cleaned up considerably. R=brettw Review URL: http://codereview.chromium.org/21342 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9745 0039d316-1c4b-4281-b951-d872f2087c98
* This is an attempt at finding the reason for the page_cycler slowness caused bymad@chromium.org2009-02-121-2/+5
| | | | | | | | | | | | | | | the new resize corner. Local experiment led me to believe that it is WebKit that is slower when we specify a resize corner area. To validate this hypothesis, I always return an empty rect to WebKit, but I still compute and push the rect to the render widget and I also draw the bitmap even if this will cause it to be drawn on top of the scroll bars when there is only one. TBR=brettw git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9654 0039d316-1c4b-4281-b951-d872f2087c98
* janitorial: browser_render_process_host header/lint cleanup. (try 2)thestig@chromium.org2009-02-111-1/+1
| | | | | | Review URL: http://codereview.chromium.org/21272 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9624 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 9594.thestig@chromium.org2009-02-111-1/+1
| | | | | | Review URL: http://codereview.chromium.org/20276 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9599 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-30 22:49:24 +0000