- made the helper Node and Iterator classes protected inner classes of List so they don't pollute the android namespace.
- use "int foo()" instead of "int foo(void)" which is more C++ stylish
- made distance() a template function, this way we write it once and it will work with combinations of iterator and const_iterator
- added the inline keyword on some function to make it clear to the compiler and the programmer that we want/intend these to be small inline functions
- added templated comparison operators to Iterator so it can compare iterator and const_iterator
- use size_t instead of "unsigned int" at places
- distance() should return a ptrdiff_t (it's kind of mening less here because it won't really work if the distance is < 0)
- made sure we handle conversions from iterator to const_iterator, but but fail at compile time in the other direction
- added operator->() on iterator and const_iterator
- made a bunch of private constructors explicit to avoid unwanted conversions
* changes:
Add support for changing a threads scheduler group. Three groups are available (default, background non interactive, foreground boost). Setting a thread priority to PRIORITY_BACKGROUND will transparently change groups to background
Add a factory method that creates a Camera object from a remote client
Next:
The changes in authordriver.cpp and android_camera_input.cpp will come.
and the constructor for Camera object will be removed.
commit 012b56fc607cf243cf4b29cb2a5f172bcbe0aecd
Author: Robert Greenwalt <robdroid@android.com>
Date: Wed Apr 22 14:31:26 2009 -0700
Additional fixes and tests for density.
commit 91fdc8e187551ae69e0029a4325fb3ad38fe411b
Author: Robert Greenwalt <robdroid@android.com>
Date: Tue Apr 14 14:39:00 2009 -0700
Fix runtime resource selection logic.
Fix isBetterThan so that o or this may be supperior at any stage.
Used to only handle this-better or tie at each stage, biasing against o.
Also allows reset of unit test to succeed. Fixes bug 1709202.
The WindowManager side of Surface.java holds a SurfaceControl, while the client-side holds a Surface. When the client is in the system process, Surface.java holds both (which is a problem we'll try to fix later).
SurfaceControl is used for controling the geometry of the surface (for the WM), while Surface is used to access the buffers (for SF's clients).
SurfaceFlingerClient now uses the SurfaceID instead of Surface*.
Currently Surface still has the SurfaceControl API and is implemented by calling into SurfaceControl.
To deal with Java's lack of destructors and delayed garbage collection, we used to duplicate Surface.cpp objects in some case; this caused some issues because Surface is supposed to be reference-counted and unique.
