re-add support for pixelformats L_8, LA_88 and RGB_332 in libui
for backward compatibility.
This may or may not fix 6058926
Bug: 6049685
Change-Id: Ic1b8b4cc994522f7fe664da64c0ef76b98bc6d53
When a drawPath command is recorded in a display list, a copy of the
source path is made to preserve against possible modifications of the
said source path. Copies are discarded when a display list is cleared,
which usually happens on invalidate(). This means that even if a path
is never modified, the texture generated to draw it on screen is
destroyed every time an invalidate() is issued. This change fixes this
problem by introducing a reference to the source path in the copy.
If both the copy and the source path have the same genID, they are
the same path and can share the same texture.
Change-Id: I34849311c183e06336a1391d2d1568a087f973f6
This does not actually change the framebuffer format. It merely
fakes this format to surfaceflinger so that when it creates
framebuffer surfaces it will use this format. It's really a giant
HACK to allow interworking with buggy gralloc+GPU driver
implementations. You should *NEVER* need to set this for shipping
devices.
Change-Id: I03eeb5b4d72838ef219df386ecc489fc20ab9cc7
Signed-off-by: Dima Zavin <dima@android.com>
This optimization allows us to quickly skip operations that lie
entirely outside of the known bounds of a display list. Because
of ViewGroup.setClipChildren, we must keep the operations recorded
in the display list. setClipChildren(false) is however a very
uncommon operation and we will therefore often benefit from this
new optimization.
Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
Move the common_time service developed in the ics-aah branch back into
master.
The common_time service is a small service build to synchronize an
arbitrary timeline amongst peers on a local sub-net. While running
and configured, the service will elect a master from the set of
available devices within the subnet, define a relationship between the
common_time timeline the local time timeline (provided by the local
time HAL), and then attempt to maintain synchronization between common
and local time by controlling the frequency of the local time clock
via the HAL, or by disciplining local time in the digital domain if
the local time HAL implementation does not support HW slewing.
On its own, the native common time service will do nothing until it is
configured. The CommonTimeManagementService (running out of the
system server process) is responsible for implementing policy
regarding configuration and operation of the common_time service and
will be added in a subsequent CL.
Change-Id: I71292f9b9b1797665865689c4572c9d3a0552f64
Signed-off-by: John Grossman <johngro@google.com>
