Packages affected: compiz, libnux
The goal is to add functional and efficient EGL/OpenGL ES 2.0 support to the OpenGL plugin of the compiz window manager and the nux OpenGL toolkit library.
We will achieve this by modifying the existing OpenGL frameworks, with the goal of having a single subset-oriented code base for both OpenGL and OpenGL ES 2.0.
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)
It is mandatory.
compiz is a very popular compositing window manager on Linux systems using the X11 window system and forms the basis for the user experience of many desktop environments. Assuming support of OpenGL, some very interesting user experience effects are possible. As ARM-based systems get more capable (both CPU and GPU), users would like to have the same experience on their embedded platforms that they get on their desktop. This is only possible if compiz supports EGL and OpenGL ES as well as GLX and OpenGL. Additionally, this new API support provides a path for compiz to non-X11 based user environments.
- Linux desktop where compositing is desired for various effects:
- Advanced desktop switching (e.g. cube-mapped desktop views).
- Ubuntu Unity plugin
- We should ensure that there is no duplication of effort (cooperate with groups that are working on this).
- We should ensure that we are in close contact with upstream and resolve any issues that could block upstream adoption.
- The target of our support is a subset of OpenGL 2.x/OpenGL ES 2.0 and higher.
- For maintainability we should strive to have a single source base for OpenGL 2.x/OpenGL ES 2.0.
- Compile-time OpenGL vs OpenGL ES selection initially (eventually, at runtime).
- Gradual porting to OpenGL ES 2.0 by replacing desktop OpenGL specific features. OpenGL should remain functional at all stages of porting.
No duplication of effort
- Announce the intentions and design ideas to the upstream mailing list and get feedback.
- Locate other groups that may be planning on (or have already started) working on a similar task and see how we can cooperate.
- Update of OpenGL functionality within compiz OpenGL plugin to reflect subset approach (see "Migration" below).
- Addition of EGL support within compiz.
- Context/surface management
- Tweaking of API usage within compiz to reflect any OpenGL ES-specific fallout.
- Update of OpenGL functionality within nux to reflect subset approach (see "Migration" below).
- Tweaking of API usage within nux to reflect any OpenGL ES-specific fallout.
- Addition of EGL support within nux for "standalone" environment.
Common topics for "modernization" of OpenGL functionality. These largely apply whether targetting OpenGL ES 2.0 or the current core profile of OpenGL.
- No more immediate mode (glBegin/glEnd). Use glDrawArrays/glDrawElements.
- Fewer primitives (no GL_QUADS, GL_QUAD_STRIP, GL_POLYGON).
- No bitmaps or polygon stipples.
- No more fixed-function vertex processing (matrix stacks, transformation API, lighting, material properties, etc.). Need matrix stack and transform library as well as vertex shaders.
- No more fixed-function fragment processing (fog, texenv, related texture and fog enables, etc.). Need fragment shaders.
- No more glCopyPixels.
- Much more, but those are the key pieces.
Executing the API conversion this way prevents breakage and regression of existing OpenGL functionality prior to OpenGL ES-specific work.
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
WorkingGroups/Middleware/Graphics/Specs/1105/CompizGLES2 (last modified 2010-12-22 16:37:23)