- this implements vec2, vec3, vec4, which are float vectors
of size 2, 3 and 4 respectively.
the code allows easy instantiation of vectors of a different
type via the tvec{2|3|4}<T> template classes.
- this also implements mat4 which is a float 4x4 matrix. the
tmat44<T> template class allows easy instantiation of a
4x4 matrix of a different value_type.
The vector types have some minimal support for the
glsl style swizzled access; for instance:
vec4 u;
vec3 v = u.xyz;
only .x, .xy, .xyz and their .stpq / .rgba equivalent are
supported.
most operators are supported on both vector and matrices:
arithmetic, unary, compound assignment and comparison
(bit-wise operators NOT supported).
- operations available on vectors include:
dot, length, distance, normalize and cross
- operations available on matrices include:
transpose, inverse, trace
- and a few utilities to create matrices:
ortho, frustum, lookAt
Change-Id: I64add89ae90fa78d3f2f59985b63495575378635
SF can spawn threads (indirectly) during initialization
and we want those to be spawned at URGENT_DISPLAY_PRIORITY
(in theory they should set their own, but some code lives
in vendor libraries and doesn't).
Bug: 10430209
Change-Id: I5b3a8f979297de287614c8eafd8267bef1176e4b
EGL now picks the buffer format out of a small set
of formats compatible with CPU consumers instead of
using the EGL_NATIVE_VISUAL_ID.
Bug: 10194508
Change-Id: If423cd29601b7a3ace8670f4c73004132cfc4b31
specifically when the display size and the screenshot window
size didn't match, the buffer would be rejected.
We simply fix this by setting the scalling mode to
"SCALE_TO_WINDOW".
Bug: 9992306
Change-Id: Ib821767899af330bb70d3cbbfa7d41b02794a075
If a layer is not cropped but its bounds are outside of the
viewport (i.e.: clipped), the crop rectangle passed to
hw composer would be invalid because it started invalid
in the first place (to indicate "no crop").
Bug: 10410944
Change-Id: I4ae4d49a1adef0be7fa4304ecf84b1a5b7d03fe0
We weren't dequeing and setting the output buffer until just before
set(). This didn't allow HWC to make decisions in prepare() based on
the output buffer format, dimensions, etc.
Now we dequeue the output buffer at the beginning of the composition
loop and provide it to HWC in prepare. In GLES-only rendering, we may
have to cancel the buffer and acquire a new one if GLES requests a
buffer with properties different than the one we already dequeued.
Bug: 10365313
Change-Id: I96b4b0a851920e4334ef05080d58097d46467ab8
it used to spawn its own thread and return the main thread
to the binder thread pool -- this was confusing the naming
of things in the kernel.
Bug: 10331839
Change-Id: I2d13a6d73409a38109300fcbe6a04b4c41cb5d00
the main reason for doing this is so that we can have
access to informations about a texture (like its dimension)
close to where we generate and use shaders in ES 2.0.
Previously, there wasn't any way to get to a texture's size
from a RenderEngine implementation.
Bug: 8679321
Change-Id: I388b338a70d07e3e8177dde248710ea1e4c82dff
This change adds an entire field to note whether the timestamp was
auto-generated by Surface or supplied by the application.
The value is used when deciding whether or not to drop frames based
on buffer presentation timestamps. If a desired presentation time
was set explicitly, BufferQueue will use that value to decide if a
frame should be dropped. If the timestamp was generated by Surface
at the time the buffer was queued, the timestamp is ignored.
Bug 10151804
Change-Id: Ibd571a7578351063b813cbdad2ddbeed70655ba5
