0
Files
src/components
kkinnunen 631033e40b command_buffer: Add support for creating non-WebGL ES 3 contexts
Add support for creating non-WebGL ES 3 contexts.

Replaces "web gl version" in context creation attributes with
"context type".

Adds an example use-case, a GL test that uses ES 3.0 context.

Makes it possible to use ES 3.0 functions exposed by command buffer.
Previously the ES 3.0 functions were removed by the linker.

Needed, because up-coming features might have ES 3.0 related code,
and that code needs to be tested. EXT_blend_func_extended is an
example of such a feature.

BUG=506765

Review URL: https://codereview.chromium.org/1325433003

Cr-Commit-Position: refs/heads/master@{#350319}
2015-09-23 06:39:41 +00:00
..
2015-09-21 14:29:58 +00:00
2015-09-18 19:59:32 +00:00
2015-08-21 22:06:45 +00:00
2015-07-31 12:33:47 +00:00
2015-08-21 01:24:18 +00:00
2015-08-21 01:24:18 +00:00
2015-09-22 17:12:14 +00:00
2015-05-01 18:45:13 +00:00
2015-09-01 23:01:22 +00:00
2015-09-21 14:29:58 +00:00
2015-05-29 00:50:09 +00:00
2015-07-16 08:35:10 +00:00
2015-07-31 12:33:47 +00:00
2015-08-21 22:06:45 +00:00
2015-07-30 08:06:36 +00:00
2015-09-04 02:37:28 +00:00

This directory is for features that are intended for reuse across multiple
embedders (e.g., Android WebView and Chrome).

By default, components can depend only on the lower layers of the Chromium
codebase(e.g. base/, net/, etc.). Individual components may additionally allow
dependencies on the content API and IPC; however, if such a component is used
by Chrome for iOS (which does not use the content API or IPC), the component
will have to be in the form of a layered component
(http://www.chromium.org/developers/design-documents/layered-components-design).

Components that have bits of code that need to live in different
processes (e.g. some code in the browser process, some in the renderer
process, etc.) should separate the code into different subdirectories.
Hence for a component named 'foo' you might end up with a structure
like the following (assuming that foo is not used by iOS and thus does not
need to be a layered component):

components/foo          - DEPS, OWNERS, foo.gypi
components/foo/browser  - code that needs the browser process
components/foo/common   - for e.g. IPC constants and such
components/foo/renderer - code that needs renderer process

These subdirectories should have DEPS files with the relevant
restrictions in place, i.e. only components/*/browser should
be allowed to #include from content/public/browser.

Note that there may also be an 'android' subdir, with a Java source
code structure underneath it where the package name is
org.chromium.components.foo, and with subdirs after 'foo'
to illustrate process, e.g. 'browser' or 'renderer':

components/foo/android/OWNERS, DEPS
components/foo/android/java/src/org/chromium/components/foo/browser/
components/foo/android/javatests/src/org/chromium/components/foo/browser/

Code in a component should be placed in a namespace corresponding to
the name of the component; e.g. for a component living in
//components/foo, code in that component should be in the foo::
namespace.