summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/renderer.scons
Commit message (Collapse)AuthorAgeFilesLines
* Bring up renderer_main on linux.estade@chromium.org2009-02-091-1/+6
| | | | | | | | | * Implement no-op sandbox functions. * Fix up the --renderer-startup-dialog dialog. Review URL: http://codereview.chromium.org/20186 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9412 0039d316-1c4b-4281-b951-d872f2087c98
* Build the rest of renderer on linux (except plugins).estade@chromium.org2009-02-051-4/+0
| | | | | | Review URL: http://codereview.chromium.org/20092 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9256 0039d316-1c4b-4281-b951-d872f2087c98
* From agl. Cleaned up version of issue 19046.thestig@chromium.org2009-02-031-2/+0
| | | | | | | | | | | | | POSIX: bitmap data on the wire On Windows, when drawing a given rect in the renderer, we allocate memory for the bitmap, render and send a shared memory handle across IPC. In the browser, we bitblit the shared memory to the backing store and draw it to the screen. In the long term, on Linux, we want the backingstore to be shared with both X and the renderer. The renderer then draws directly to that store, sends an IPC to the browser and the browser sends a message to X to bitblit to the display. Since only cache a few backing stores we'll need messages from the browser to tell the renderer to attach and detatch from shared memory regions as they get created and evicted. In the short term, however, to get something that works, we make a BitmapWireData typedef. This will be a shared memory region on Windows, as before, and on POSIX we'll be sending the bitmap data over the wire. Obviously this'll be pretty slow but it'll work sooner. Review URL: http://codereview.chromium.org/19491 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9065 0039d316-1c4b-4281-b951-d872f2087c98
* A little porting in chrome/renderer.estade@chromium.org2009-01-271-1/+0
| | | | | | Review URL: http://codereview.chromium.org/19045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8766 0039d316-1c4b-4281-b951-d872f2087c98
* render_* work.jrg@chromium.org2009-01-271-4/+0
| | | | | | Review URL: http://codereview.chromium.org/18650 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8732 0039d316-1c4b-4281-b951-d872f2087c98
* Checking in stubbed out ChromeMediaPlayer filter implementations.scherkus@chromium.org2009-01-261-0/+9
| | | | | | Review URL: http://codereview.chromium.org/18538 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8652 0039d316-1c4b-4281-b951-d872f2087c98
* POSIX: get bits of renderer_glue compilingagl@chromium.org2009-01-231-1/+0
| | | | | | | Review URL: http://codereview.chromium.org/16817 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8541 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: don't want to build render_process till ph_ submits his DNS patchagl@chromium.org2009-01-221-0/+1
| | | | | | | Review URL: http://codereview.chromium.org/18645 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8437 0039d316-1c4b-4281-b951-d872f2087c98
* POSIX: Porting renderer/render_process.cc, low hanging fruitagl@chromium.org2009-01-221-1/+0
| | | | | | | Review URL: http://codereview.chromium.org/18622 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8436 0039d316-1c4b-4281-b951-d872f2087c98
* Generate all chrome .vcproj files:sgk@google.com2009-01-171-18/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Path name translation (/ to \) of various MSVSTool attributes. * Explicit keyword= arguments to MSVSProject. This will likely go away eventually in favor of uniform behavior. * Add a relative_path_substitutions array that can be used to substitute in Visual Studio variable like $(OutDir). * Add a local_directory_prefix that can be set to './' to only affect files in the current directory. * Additional Keyword ordering in Tool attributes to continue to match the default order Visual Studio generates. * Add a Derived() proxy class that can wrap a File node to tell the .vcproj generation that we want the derived file, not its source(s), in the file list. * In the individual *.scons files, add the necessary files (mostly .h files) to file lists, and update MSVSProject() calls with the additional necessary information. Result is identical .vcproj files modulo the following differences: * Four locales .vcproj files (da, en-US, he and zh-TW) with source file orders that don't match the other locale .vcproj files have re-ordered file lists to match the rest. * Cosmetic XML changes (white space, ending tags) in: chrome/app/chrome_dll.vcproj chrome/app/generated_resources.vcproj net/build/net_resources.vcproj * Removal or addition of ./ prefixes from various files that don't match the other file specifications within their individual .vcproj files: chrome/installer/util/util.vcproj net/build/net.vcproj net/build/net_unittests.vcproj * Add missing empty sections (<ToolFiles>, <References>, <Globals>) for consistency with other .vcproj files: chrome/tools/test/image_diff/image_diff.vcproj third_party/libpng/libpng.vcproj third_party/zlib/zlib.vcproj * Add missing RootNameSpace attribute: chrome/test/automation/automation.vcproj testing/gtest.vcproj * Use && instead of \r\n as a command separator, to sidestep XML-generation problems: chrome/app/chrome_exe.vcproj * Remove unnecessary (?) duplicate files in the file list: chrome/browser/views/browser_views.vcproj (event_utils.cc and event_utils.h were duplicated) Review URL: http://codereview.chromium.org/17603 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8253 0039d316-1c4b-4281-b951-d872f2087c98
* This is a rename of the term 'Greasemonkey' to 'user script' in Chromium.aa@chromium.org2009-01-091-1/+1
| | | | | | | | | | | I'm doing this to avoid confusion with the Firefox version of Greasemonkey and also because 'user script' is really the correct generic term. At the same time, I also moved user_script_master* into extensions/ because I want these two pieces to get closer and closer such that standalone user scripts are just a very small extension. Also extensions will be relying on most of the user script code. Review URL: http://codereview.chromium.org/17281 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7827 0039d316-1c4b-4281-b951-d872f2087c98
* adding more grit love to other targets, updating scons files for things that ↵pinkerton@google.com2009-01-071-9/+1
| | | | | | | | work on mac. moving the shell script phase to a standalone target to share it between targets. adding new unit test files. Review URL: http://codereview.chromium.org/16585 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7675 0039d316-1c4b-4281-b951-d872f2087c98
* Add using_generated_resources.scons to the build. Thistc@google.com2009-01-061-1/+1
| | | | | | | | | | | is the same as using_generated_resources.vsprops. Replace existing paths with this scons file if the SConscript file has already been converted to the using_ format. Review URL: http://codereview.chromium.org/14902 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7583 0039d316-1c4b-4281-b951-d872f2087c98
* Mass convert ChromeStaticLibrary -> ChromeLibrary, including pulling the ↵evanm@google.com2008-12-261-1/+1
| | | | | | | | | | | updated ICU dep that uses it as well. Add a SHARED scons command-line flag to build shared libraries. Review URL: http://codereview.chromium.org/16477 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7479 0039d316-1c4b-4281-b951-d872f2087c98
* Initial generation of native Visual Studio solution filessgk@google.com2008-12-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (project files still to come). To wit: * Solution file configuration is in *_sln.scons files (base\base_sln.scons, chrome\chrome_sln.scons). * Individual Project file configuration is in the the .scons file for the relevant target (base\base_unittests.scons, third_party\libxml\libxml.scons, etc.)--that is, where their file lists will live. * MSVSProject() calls are currently placeholders that establish the existence of Project Nodes (and Project dependencies) but don't yet have actual Project configuration information (file lists, .vsprops, etc.). * Configuraiton is very manual. In particular, the entries in the .sln file will be written out in exactly the order specified in the configuration(s). The current ordering is taken from our existing .sln files, so we can generate virtually the same configurations on output. * Generated solution files are nearly byte-for-byte identical with our existing .sln files, modulo: * net\dump_cache has a WebsiteProperties sections (making that configurable per project isn't important right now); * sandbox\sandbox.sln was missing a dependency of base.vcproj on on debug_message.vcproj (present in other .sln files) * webkit\webkit.sln was missing dependencies of WebCore.vcproj on libxml_config.vcproj and libxslt_config.vcproj (present in chrome.sln); * add a handful of other miscellaneous missing dependencies on various .vcproj definitions in chrome.sln (present in other .sln files). * remove stats_viewer.csproj from chrome.sln (sorry, mbelshe), which was complicating the solution configuration with unnecessary (for us) "Mixed Platform" types; * All MSVSFolder(), MSVSProject() and MSVSSolution() calls have hard-wired guid= values taken from our existing configuration, so we can: 1) verify generation of working configs; 2) minimize diffs when checking in generated .sln files. We can remove these in the future in favor of extracting them from existing .sln files if we wish. * Add ChromeMSVSFolder(), ChromeMSVSProject() and ChromeMSVSSolution() wrappers to chromium_builders.py, that gate the underlying call to the env.MSVS*() builders based on whether env.Bit('msvs') is set (i.e., we're in --mode=msvs). * Remove platform-specific gating of to-be-ported .scons files that we now need to load on any platform to generate coheren MSVS files. Move the env.Bit('windows') tests for actually building their executables into the individual .scons files. Review URL: http://codereview.chromium.org/14472 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7297 0039d316-1c4b-4281-b951-d872f2087c98
* Convert from using env['PLATFORM'] directly to using the more flexiblesgk@google.com2008-12-181-4/+4
| | | | | | | | | | | | | | | | | | and better-thought-out Hammer env.Bits() idioms: * env['PLATFORM'] == 'win32' => env.Bit('windows') * env['PLATFORM'] == 'posix' => env.Bit('linux') * env['PLATFORM'] == 'darwin' => env.Bit('mac') New idioms: * env.Bit('posix') => really does mean "any POSIX platform" * env.AnyBits('mac', 'linux') => specifically mac or linux, excluding other POSIX platforms Where we were using compound conditionals (e.g., "env['PLATFORM'] in ('posix', 'darwin')") I tried to take my best shot at translating the intent (i.e., "env.Bits('posix')" for something POSIX, "not env.Bits('mac')" for something not yet ported to Mac, etc.) Review URL: http://codereview.chromium.org/15051 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7270 0039d316-1c4b-4281-b951-d872f2087c98
* Bridge out media player from MediaPlayerPrivate.hclam@chromium.org2008-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Remove MediaPlayerPrivateChromium.cpp and move it to webkit/glue/media_player_private_impl.cc - Added the following classes: WebMediaPlayer WebMediaPlayerImpl WebMediaPlayerDelegate WebMediaPlayerDelegateImpl TestWebMediaPlayerDelegate VideoStackMediaPlayer (Just a forward declaration) - One include fix for webkit/glue/webframe.h - Overview of what each class is doing: WebMediaPlayer and WebMediaPlayerImpl Wrapper over the MediaPlayerPrivate, it provides methods like Repaint(), NotifyNetworkStateChange(), etc to VideoStackMediaPlayer. It also creates the ResourceHandle for VideoStackMediaPlayer for resource loading, or maybe VideoStackMediaPlayer can simply use webkit_glue::ResourceDispatcher? WebMediaPlayerDelegate, WebMediaPlayerDelegateImpl Delegate calls from webkit to the internal media player. MediaPlayerPrivate Forward calls to WebMidiaPlayerDelegate, creates WebMediaPlayerDelegate and WebMediaPlayer in the constructor. Expose some public methods to WebMediaPlayer so we can actually do repaint and notification of changes. Review URL: http://codereview.chromium.org/13762 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7256 0039d316-1c4b-4281-b951-d872f2087c98
* Porting in renderer/phajdan.jr@chromium.org2008-12-181-5/+0
| | | | | | Review URL: http://codereview.chromium.org/15601 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7217 0039d316-1c4b-4281-b951-d872f2087c98
* Have GRIT generate files into a common directory.tc@google.com2008-12-121-1/+1
| | | | | | | | | | | | | | | Joi has convinced me that GRIT should generate platform specific resources files. This is easier than parsing .rc files because GRIT effectively has an .rc parser. To that end, we need to convert some existing .rc files to .grd files (e.g., net_resources.rc and webkit_resources.rc). Rather than having every grd file output to a different place and -I all the different paths, have GRIT generate all files into one directory. This directory is grit_derived_sources. Review URL: http://codereview.chromium.org/13776 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6940 0039d316-1c4b-4281-b951-d872f2087c98
* add more files to mac chrome project, build a few more tests. Fix typo in ↵pinkerton@google.com2008-12-021-1/+1
| | | | | | | | scons file for darwin. Use compiler define for MSVC pragma. Review URL: http://codereview.chromium.org/13060 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6244 0039d316-1c4b-4281-b951-d872f2087c98
* Convert chrome\renderer to new SCons naming.sgk@google.com2008-11-031-0/+109
Review URL: http://codereview.chromium.org/9053 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4510 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-08 03:32:02 +0000