When a display is added, initialize it to use an empty layer stack, so
if it is somehow visible it will show black. It will be assigned the
real layer stack -- along with a projection and other properties -- by
window manager soon. Normally a display remains blanked until window
manager has decided what to show on it, but for HDMI connected at boot
that isn't currently the case.
Bug: 7258935
Change-Id: Ic9bb25f7a9b8d9d3772b097ab1d6fa03bc8780a1
- cropping to the projection's "viewport" is "simply"
accomplished by intersecting it with the window crop
expressed in layerstack space.
Bug: 7149437
Change-Id: I0e90b3f37945292314b5d78a8f134935967e8053
- the crop region is now always calculated and set
in LayerBase::setGeometry which uses new virtuals to
access the "content" crop and transform (which are
provided by the Layer subclass)
Change-Id: Ib7769bdec0917dd248f926600c14ddf9ea84897a
each desplay's projection's viewport essentially clips each layer,
so this should be reflected in the visibleregion passed to
h/w composer.
DisplayDevice getViewport and getFrame are now guaranteed to return
valid Rects.
Change-Id: I4c25f34fb26af10179eb26d429ca6c384c671e91
The crop always had left=top=0, because the crop position
and the layer's transform were merged together in
computeBounds() (which really used to compute the
bounds in screen space, which we usually call the
"frame" elsewhere in the code)
Note: in practice this crop value is not used by
hwc, because it's overridden in Layer::setGeometry(), which
is why this bug was never apparent.
Change-Id: I1ec6400a8fc8314408e4252708f43ea98c2fe64e
T-junction free regions are useful for rendering regions with various
geometric transformations, and the Region's span-ordered, sorted rect
list supports T-junction free storage without modification.
This approach creates a T-junction free region by splitting each
rectangle that is part of a vertical T-junction. This approach is two
pass (up and down) so that divisions can trickle up/down to other
adjacent spans.
Change-Id: Ifcf5e6fe0034c96b00ef09a4433b2b0fce8f4300
We check that calling eglSwapBuffers() on an abandonned BufferQueue
return EGL_BAD_SURFACE -- this is to ensure consistancy between
drivers.
Change-Id: Ibb548e0cf767ceee69f2fc4a85811d15a6522277
- added support for comments in checks.spec
- added most missing checks
- added and commented with // special-cased functions
- added and commented with # functions that are still missing validation checks
- moved glGet* to a special case and updated all the "pnames" from the khronos spec
- changed ifcheck to default to 1 value. this allows us to simplify the checks.spec file
and handle unknown pnames automatically (they'll be validated against 1 value, if
it happens to need more, the call will go through but the validation will not
happen).
- refactored the cpp headers in to a common header + GLES version specific
header
Bug: 7402895
Change-Id: Ib5c68ca0ca416407b4cfa36e3a21901b2d6263ab
This change replaces checks for a NULL fence pointer with calls to
Fence::isValid. There should no longer be NULL fences.
Change-Id: If17c9c132fcb1801531bf7588f8ba53476c57dad
* changes:
Symlink /system/lib/libGLESv3.so -> libGLESv2.so
Add ES3 support to libGLESv2 and tracing tools
Import OpenGL ES 3.0 headers from Khronos SVN
- it looks like UserId has been renamed to UserHandle in the
framework.
- also for some reason I don't understand glgen didn't seem
to be up to date with respect to the generated bindings in the tree.
It's like the bindings were generated with a more recent version of
glgen (maybe it was never checked in). So we fix that here.
Change-Id: Ie49522ebf67fcab9213246b4d93500e37a3cbc05
The platform has a unified GLES2/GLES3 wrapper in libGLESv2.so, which
is what bundled binaries should link against. The NDK will have
separate GLES2 and GLES3 libraries so that applications will get a
link error if they accidentally use GLES3 entry points in a GLES2
application. This symlink allows GLES3 NDK apps to load using the
unified wrapper.
Change-Id: Ic344ef63c334047fccebb55b7cb2fb23a4c2d61b
This change eliminates the uses of a NULL sp<Fence> indicating that no waiting
is required. Instead we use a non-NULL but invalid Fence object for which the
wait methods will return immediately.
Bug: 7892871
Change-Id: I5360aebe3090422ef6920d56c99fc4eedc642e48
