Ddanakj@chromium.orgAdd the ubercomp DelegatedRendererLayer.
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Fix up cc stubs and bindings to work in windows Windows is stricter than other platforms in a few ways: *) All files referenced in a .gyp have to actually exist or the generator complains *) Symbols have to be defined in only one object file *) NO_ERROR is #defined by some win32 headers and collides with GL headers *) WEBKIT_DLL has to be set for targets that define exported symbols This fixes these in the cc stubs. BUG= Review URL: https://chromiumcodereview.appspot.com/10915074 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154899 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Enable webkit_compositor_bindings_unittests in component builds This shares the compositor setup code from cc_unittests so we can run webkit_compositor_bindings_unittests in component builds. BUG= Review URL: https://chromiumcodereview.appspot.com/10918281 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157416 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add more cc OWNERS Let's start here and iterate as needed. BUG= Review URL: https://chromiumcodereview.appspot.com/10917230 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156501 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add the ubercomp DelegatedRendererLayer. This adds a layer that owns a set of RenderPasses with DrawQuads, and is able to insert those RenderPasses and DrawQuads into the current frame during CCLayerTreeHostImpl::calculateRenderPasses(). The layer owns whatever quads/passes you give to it, and copies them with modifications as needed into the current frame via the QuadSink. Quads from the layer's root RenderPass are merged into its target RenderPass, with the transform and opacity being modified if needed. Other RenderPasses are inserted into the frame as-is, with RenderPass ids being adjusted to not collide with any other RenderPasses in the frame, and using a scheme that allows the layer to reverse-lookup its own copy of a RenderPass from the id it generated. Moved from: https://bugs.webkit.org/show_bug.cgi?id=94145 Tests: CCDelegatedRendererLayerImplTestSimple.AddsContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestSimple.QuadsFromRootRenderPassAreModifiedForTheTarget CCDelegatedRendererLayerImplTestOwnSurface.AddsRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestOwnSurface.QuadsFromRootRenderPassAreNotModifiedForTheTarget BUG=123445 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157700 Review URL: https://chromiumcodereview.appspot.com/10916307 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157794 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add the ubercomp DelegatedRendererLayer. This adds a layer that owns a set of RenderPasses with DrawQuads, and is able to insert those RenderPasses and DrawQuads into the current frame during CCLayerTreeHostImpl::calculateRenderPasses(). The layer owns whatever quads/passes you give to it, and copies them with modifications as needed into the current frame via the QuadSink. Quads from the layer's root RenderPass are merged into its target RenderPass, with the transform and opacity being modified if needed. Other RenderPasses are inserted into the frame as-is, with RenderPass ids being adjusted to not collide with any other RenderPasses in the frame, and using a scheme that allows the layer to reverse-lookup its own copy of a RenderPass from the id it generated. Moved from: https://bugs.webkit.org/show_bug.cgi?id=94145 Tests: CCDelegatedRendererLayerImplTestSimple.AddsContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestSimple.QuadsFromRootRenderPassAreModifiedForTheTarget CCDelegatedRendererLayerImplTestOwnSurface.AddsRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestOwnSurface.QuadsFromRootRenderPassAreNotModifiedForTheTarget BUG=123445 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157700 Review URL: https://chromiumcodereview.appspot.com/10916307 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157794 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add scrolling related getters to WebLayerImpl This patch adds a number of scrolling related getters to WebLayerImpl and LayerChromium for testing purposes. They will be used by the ScrollingCoordinatorChromium test (http://webkit.org/b/96657). Note that the WebLayerImpl getters aren't marked with OVERRIDE because the corresponding changes to WebLayer aren't in place yet. This will be corrected later. BUG=none Review URL: https://chromiumcodereview.appspot.com/10909233 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157101 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add scrolling related getters to WebLayerImpl This patch adds a number of scrolling related getters to WebLayerImpl and LayerChromium for testing purposes. They will be used by the ScrollingCoordinatorChromium test (http://webkit.org/b/96657). Note that the WebLayerImpl getters aren't marked with OVERRIDE because the corresponding changes to WebLayer aren't in place yet. This will be corrected later. BUG=none Review URL: https://chromiumcodereview.appspot.com/10909233 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157101 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Update cc snapshot to r127918 TBR=nduca@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/10917153 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@155554 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Enable webkit_compositor_bindings_unittests in component builds This shares the compositor setup code from cc_unittests so we can run webkit_compositor_bindings_unittests in component builds. BUG= Review URL: https://chromiumcodereview.appspot.com/10918281 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157416 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Change cc files from namespace WebCore to cc These files no longer are part of WebCore, so it doesn't make any sense to keep that namespace. Due to being unable to forward declare typedefs in C++, the stubs files (like FloatSize) now define cc::FloatSize as being derived from WebCore::FloatSize. With enough constructors, this lets them be used interchangably in the short term until those geometry classes become real and not dependent on WebCore files. This allows (nearly) all the forward declarations and uses of these types in cc stay as-is with minimal churn. BUG=none Review URL: https://codereview.chromium.org/10914268 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@156905 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Fix cc gyp files up for static linking TBR=nduca@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/10909145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@155912 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add the ubercomp DelegatedRendererLayer. This adds a layer that owns a set of RenderPasses with DrawQuads, and is able to insert those RenderPasses and DrawQuads into the current frame during CCLayerTreeHostImpl::calculateRenderPasses(). The layer owns whatever quads/passes you give to it, and copies them with modifications as needed into the current frame via the QuadSink. Quads from the layer's root RenderPass are merged into its target RenderPass, with the transform and opacity being modified if needed. Other RenderPasses are inserted into the frame as-is, with RenderPass ids being adjusted to not collide with any other RenderPasses in the frame, and using a scheme that allows the layer to reverse-lookup its own copy of a RenderPass from the id it generated. Moved from: https://bugs.webkit.org/show_bug.cgi?id=94145 Tests: CCDelegatedRendererLayerImplTestSimple.AddsContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestSimple.QuadsFromRootRenderPassAreModifiedForTheTarget CCDelegatedRendererLayerImplTestOwnSurface.AddsRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestOwnSurface.QuadsFromRootRenderPassAreNotModifiedForTheTarget BUG=123445 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157700 Review URL: https://chromiumcodereview.appspot.com/10916307 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157794 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add some missing unit tests and update cc_unittests and webkit_compositor_bindings_unittests After GTFO, some unit test files were not in the right place, or missing entirely. This patch (1) adds some missing unit tests, (2) moves some tests from webkit_compositor_bindings_unitttests to cc_unitttests, and (3) removes some redundant entries in the gyp files for those targets. BUG=https://code.google.com/p/chromium/issues/detail?id=149121 Review URL: https://chromiumcodereview.appspot.com/10909218 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157425 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Make cc_unittests and webkit_compositor_unittests executable always To get these tests set up to run on the bots they need to be executables always. If use_libcc_for_compositor is 0 these targets won't run any tests, but they will still successfully run. TBR=joth@chromium.org (for stupid android_webview copyright script) BUG= Review URL: https://chromiumcodereview.appspot.com/10920056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154620 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add the ubercomp DelegatedRendererLayer. This adds a layer that owns a set of RenderPasses with DrawQuads, and is able to insert those RenderPasses and DrawQuads into the current frame during CCLayerTreeHostImpl::calculateRenderPasses(). The layer owns whatever quads/passes you give to it, and copies them with modifications as needed into the current frame via the QuadSink. Quads from the layer's root RenderPass are merged into its target RenderPass, with the transform and opacity being modified if needed. Other RenderPasses are inserted into the frame as-is, with RenderPass ids being adjusted to not collide with any other RenderPasses in the frame, and using a scheme that allows the layer to reverse-lookup its own copy of a RenderPass from the id it generated. Moved from: https://bugs.webkit.org/show_bug.cgi?id=94145 Tests: CCDelegatedRendererLayerImplTestSimple.AddsContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestSimple.QuadsFromRootRenderPassAreModifiedForTheTarget CCDelegatedRendererLayerImplTestOwnSurface.AddsRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestOwnSurface.QuadsFromRootRenderPassAreNotModifiedForTheTarget BUG=123445 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157700 Review URL: https://chromiumcodereview.appspot.com/10916307 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157794 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Add the ubercomp DelegatedRendererLayer. This adds a layer that owns a set of RenderPasses with DrawQuads, and is able to insert those RenderPasses and DrawQuads into the current frame during CCLayerTreeHostImpl::calculateRenderPasses(). The layer owns whatever quads/passes you give to it, and copies them with modifications as needed into the current frame via the QuadSink. Quads from the layer's root RenderPass are merged into its target RenderPass, with the transform and opacity being modified if needed. Other RenderPasses are inserted into the frame as-is, with RenderPass ids being adjusted to not collide with any other RenderPasses in the frame, and using a scheme that allows the layer to reverse-lookup its own copy of a RenderPass from the id it generated. Moved from: https://bugs.webkit.org/show_bug.cgi?id=94145 Tests: CCDelegatedRendererLayerImplTestSimple.AddsContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestSimple.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestSimple.QuadsFromRootRenderPassAreModifiedForTheTarget CCDelegatedRendererLayerImplTestOwnSurface.AddsRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToContributingRenderPasses CCDelegatedRendererLayerImplTestOwnSurface.AddsQuadsToTargetRenderPass CCDelegatedRendererLayerImplTestOwnSurface.QuadsFromRootRenderPassAreNotModifiedForTheTarget BUG=123445 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=157700 Review URL: https://chromiumcodereview.appspot.com/10916307 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@157794 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Don't depend on WEBKIT_IMPLEMENTATION guarded geometry conversion c'tors Since these files compile without WEBKIT_IMPLEMENTATION set the implicit WebRect -> WebCore::IntRect and related conversion c'tors aren't available. This defines a set of utility convert() functions and uses those to make the conversions explicit. When we switch CC geometry types we can delete these (if the cc API ends up using gfx:: types) or switch them to convert to the cc types. BUG= Review URL: https://chromiumcodereview.appspot.com/10915165 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@155887 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 | |
Don't depend on WEBKIT_IMPLEMENTATION guarded geometry conversion c'tors Since these files compile without WEBKIT_IMPLEMENTATION set the implicit WebRect -> WebCore::IntRect and related conversion c'tors aren't available. This defines a set of utility convert() functions and uses those to make the conversions explicit. When we switch CC geometry types we can delete these (if the cc API ends up using gfx:: types) or switch them to convert to the cc types. BUG= Review URL: https://chromiumcodereview.appspot.com/10915165 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@155887 0039d316-1c4b-4281-b951-d872f2087c98 | 13 年前 |