summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/webplugin_delegate_proxy.h
Commit message (Collapse)AuthorAgeFilesLines
* Improve scrolling performance when there are many windowed plugins in a page.jam@chromium.org2009-01-161-5/+1
| | | | | | | | This works by parenting windowed plugins with an HWND that's hosted in the browser process, so that no synchronous cross process messages are used when scrolling. BUG=5428 Review URL: http://codereview.chromium.org/18082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8239 0039d316-1c4b-4281-b951-d872f2087c98
* WaitableEvent is the replacement for Windows events. Previously in the code, ↵agl@chromium.org2009-01-151-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a HANDLE from CreateEvent was used for signaling, both within a process and across processes. WaitableEvent is the cross platform replacement for this. To convert: * HANDLE -> base::WaitableEvent* * ScopedHandle -> scoped_ptr<base::WaitableEvent> * CreateEvent -> new base::WaitableEvent * SetEvent -> base::WaitableEvent::Signal * ResetEvent -> base::WaitableEvent::Reset * ObjectWatcher -> base::WaitableEventWatcher * WaitForMultipleObjects -> static base::WaitableEvent::WaitMany ObjectWatcher remains for Windows specific code. WaitableEventWatcher has an identical interface save, * It uses WaitableEvents, not HANDLEs * It returns void from StartWatching and StopWatcher, rather than errors. System internal errors are fatal to the address space IMPORTANT: There are semantic differences between the different platforms. WaitableEvents on Windows are implemented on top of events. Windows events work across process and this is used mostly for modal dialog support. Windows events can be duplicated with DuplicateHandle. On other platforms, WaitableEvent works only within a single process. In the future we shall have to replace the current uses of cross-process events with IPCs. BEWARE: HANDLE, on Windows, is a void *. Since any pointer type coerces to void *, you can pass a WaitableEvent * where a HANDLE is expected without any build-time errors. Review URL: http://codereview.chromium.org/16554 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8126 0039d316-1c4b-4281-b951-d872f2087c98
* Move plugins to FilePaths, some cleanupavi@google.com2009-01-061-2/+2
| | | | | | Review URL: http://codereview.chromium.org/16456 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7588 0039d316-1c4b-4281-b951-d872f2087c98
* Move the "platform" wrappers in skia/ext to the skia namespace.brettw@google.com2008-12-171-6/+6
| | | | | | Review URL: http://codereview.chromium.org/14110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7182 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing build bustage. Adding files which were part of the original changeananta@chromium.org2008-12-051-0/+1
| | | | | | | | | | branch r6396, which was reverted partially. TBR=jam Review URL: http://codereview.chromium.org/13215 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6460 0039d316-1c4b-4281-b951-d872f2087c98
* Don't cancel the original manual data stream request when the plugin invokesananta@chromium.org2008-12-041-1/+0
| | | | | | | | | | | | | | | | | | | | NPN_RequestRead to initiate seekable byte range requests on the stream. While the contract on the plugins part is not fully clear from the mozilla docs, this is what Firefox does. This also improves performance greatly as the manual data stream already has most of the data which the plugin requests anyway. I verified this with large PDF files around 14-15MB. We are twice as faster with this fix. This fixes http://code.google.com/p/chromium/issues/detail?id=5009, which is an issue with the PDF file not loading at times. The problem also occurs at times in Firefox when we set breakpoints and thus slow down the operation. The Reader plugin displays its UI in child windows on a separate thread in the plugin process. These are parented to the plugin window which lives on the plugin thread. The plugin thread unfortunately is treated as an IO thread by the plugin and it uses the SendMessage API to send messages to the plugin thread and back. If the plugin fails to receive data for the PDF file in a reasonable time, it just destroys the PDF window hierarchy causing this issue. Handing the data off the manual data stream along with the byte range data speeds up the whole operation and thus avoids this issue to a great extent. Bug=5009 R=jam Review URL: http://codereview.chromium.org/12960 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6396 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the painting problem with Stree View and Flash 10. After the size of ↵jam@chromium.org2008-12-011-1/+2
| | | | | | | | | | | the plugin changes, we generate a new backing store. Flash 9 invalidates the rectangle, but Flash 10 doesn't. As a result we paint from a blank backing store. The fix is to keep track of which part of the backing store has been painted into by the plugin, and if the renderer tries to paint an area that falls outside of it, do a synchronous paint. Also get rid of first_paint_, as it was introduced during a failed attempt to make plugin loading asynchronous. Review URL: http://codereview.chromium.org/10792 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6128 0039d316-1c4b-4281-b951-d872f2087c98
* Add Terminate() to the Process object, have RenderProcessHost use this to ↵brettw@google.com2008-11-141-4/+4
| | | | | | | | | | avoid some more Windows specific code. Move Process and SharedMemory into the base namespace (most changes). Review URL: http://codereview.chromium.org/10895 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5446 0039d316-1c4b-4281-b951-d872f2087c98
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-091-1/+4
| | | | | | | | | | | | | | | Implement "iframe shim" behavior for windowed plugins. In FF and IE on windows, iframes are implemented as native HWNDs. This has the side effect that iframes display on top of windowed plugins. This side effect has long been known as a workaround for allowing HTML elements to appear above plugin content. BUG=1788 Review URL: http://codereview.chromium.org/7032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3137 0039d316-1c4b-4281-b951-d872f2087c98
* Fix painting problem with transparent plugins because plugins were ignoring ↵jam@chromium.org2008-10-011-7/+29
| | | | | | | | | | | | | | | the alpha channel sometimes. This change introduces another buffer which holds the background image for transparent plugins. Before painting these plugins, their backing store is overwritten with the background data. This change also uses an ACK from the renderer to figure out when it can paint, similar to how the renderer does it, which gives us throttling and also doesn't lead to painting when the tab is hidden. Review URL: http://codereview.chromium.org/5040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2744 0039d316-1c4b-4281-b951-d872f2087c98
* Desynchronize windowless plugin painting. This greatly improves the paintingjam@chromium.org2008-09-221-1/+12
| | | | | | | | performance when there are multiple plugins, or when scrolling. Review URL: http://codereview.chromium.org/3133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2459 0039d316-1c4b-4281-b951-d872f2087c98
* This CB fixes the following issue1. ↵iyengar@google.com2008-09-191-1/+7
| | | | | | | | http://code.google.com/p/chromium/issues/detail?id=206This is a performance issue while loading PDF documents. The fix is to support PDF fast webview, which is basically support for the NPN_RequestRead API, which allows a plugin to request specific byte ranges in HTTP GET requests. This also needs support for seekable streams. Our support for seekable streams is limited to HTTP servers which allow byte range requests. Firefox also supports a mode in which the the browser caches the file on disk for servers which don't support byte range requests. The plugin_data_stream.cc/.h files are being removed as there is not much value in their existence. The needed functionality is available in the PluginStreamUrl class, which now services manual data streams as well. Testing this is a touch tricky as we need a HTTP server which serves byte range requests. Will add those in a subsequent CB.Also fixed a bug in the multipart parser where we need to ignore leading newline characters while parsing the header.Bug=206 Review URL: http://codereview.chromium.org/2896 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2400 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes http://b/issue?id=1303133, which was a crashiyengar@google.com2008-08-021-1/+4
| | | | | | | | | | | | in the renderer due to the plugin instance getting destroyed in the context of the ShowModalHTMLDialog request. The fix is to convert the WebPluginDelegateProxy object in a DeleteLater and to set its channel to NULL in the destructor. This ensures that the reply to the message can be sent out successfully. Bug=1303133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@286 0039d316-1c4b-4281-b951-d872f2087c98
* Add chrome to the repository.initial.commit2008-07-261-0/+175
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-02 07:29:09 +0000