| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
|
|
|
|
|
|
|
| |
(in this case the state is dumped without the proper locks held which could result to a crash)
in addition, the last transaction and swap times are printed to the dump as well as the time spent
*currently* in these function. For instance, if SF is unresponsive because eglSwapBuffers() is stuck,
this will show up here.
|
|
|
|
|
| |
what happened is that the efective pixel format is calculated by SF but Surface nevew had access to it directly.
in particular this caused query(FORMAT) to return the requested format instead of the effective format.
|
|
|
|
| |
of memory
|
|
|
|
|
|
|
| |
this would happen is the window is made visible but the client didn't render yet into it. This happens often with SurfaceView.
Instead of filling the window with solid black, SF would simply ignore it which could lead to more disturbing artifacts.
in theory the window manager should not display a window before it has been drawn into, but it does happen occasionnaly.
|
|
|
|
|
|
| |
automatically if needed.
this also ripples into the window manager API by making some constant there deprecated as well.
|
| |
|
| |
|
|
|
|
| |
"SurfaceFlinger will now allocate buffers based on the usage specified by the clients. This allows to allocate the right kind of buffer automatically, without having the user to specify anything."
|
|
|
|
| |
"SurfaceFlinger will now allocate buffers based on the usage specified by the clients. This allows to allocate the right kind of buffer automatically, without having the user to specify anything."
|
|
|
|
|
|
| |
specified by the clients. This allows to allocate the right kind of buffer automatically, without having the user to specify anything."
This reverts commit 8b76a0ac6fbf07254629ed1ea86af014d5abe050.
|
|
|
|
|
|
|
| |
clients. This allows to allocate the right kind of buffer automatically, without having the user to specify anything.
This change makes SurfaceHolder.setType(GPU) obsolete (it's now ignored).
Added an API to android_native_window_t to allow extending the functionality without ever breaking binary compatibility. This is used to implement the new set_usage() API. This API needs to be called by software renderers because the default is to use usage flags suitable for h/w.
|
| |
|
| |
|
| |
|
|
|
|
| |
or native window type
|
|
|
|
| |
chance of success
|
|
|
|
|
|
|
|
|
|
|
|
| |
scalled
The current gralloc allocates buffer memory for render targets that will typically have NPOT dimensions. Assuming that the vendor driver supports converting the resulting NPOT android_native_buffer_t to a NPOT EGLImage, SurfaceFlinger calls glEGLImageTargetTexture2DOES(), and uses glGetError() to test whether the GL can support creating an EGL target texture with the specified NPOT EGLImage. If it is supported, the DIRECT_TEXTURE flag remains set, otherwise it is cleared.
Tangentially, if the driver advertises the GL_ARB_texture_non_power_of_two extension, the NPOT_EXTENSION flag is set, otherwise it is cleared.
If the driver supported creating an EGL target texture from a NPOT source EGLImage, it implicitly creates a NPOT texture. This does not need any glScalef() texture coordinate correction in LayerBase::drawWithOpenGL(). However, the same driver may not advertise the GL_ARB_texture_non_power_of_two extension nor generally support NPOT textures that were not derived from EGLImages. So SurfaceFlinger may flag only DIRECT_TEXTURE, not NPOT_EXTENSION.
Therefore, the test in LayerBase::drawWithOpenGL() should only perform the glScalef() if neither NPOT_EXTENSION or DIRECT_TEXTURE are flagged. Otherwise scaling is applied to NPOT EGL target textures when none is required.
|
|\
| |
| |
| |
| |
| |
| | |
Merge commit '1521cd6e657ba4efa9382ab73d3cbba3bdf50ead'
* commit '1521cd6e657ba4efa9382ab73d3cbba3bdf50ead':
Reset the mDpiX and mDpiY values when qemu.sf.lcd_density is defined.
|
| |\
| | |
| | |
| | |
| | | |
* changes:
Reset the mDpiX and mDpiY values when qemu.sf.lcd_density is defined.
|
| | |
| | |
| | |
| | |
| | | |
This will make android.view.Display return corresponding values for
the screen's DPI.
|
| | | |
|
|\ \ \
| |/ / |
|
| |/ |
|
| |
| |
| |
| | |
Cupcake
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
be called at least once on each overlay, and it appears that sometimes this
doesn't happen because the visibility never changes. With this change
the overlay parameter and position will be committed when either the visibility
of the window changes, or on the first call to visibility resolved, if it
hasn't already been done.
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
internally pthread uses futex. the implementation consists of simple inlines
there are no implementation files anymore.
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
* changes:
fix [1969200] Uninitialized double passed to Math.sqrt()
|
| | | |
|
|\ \ \
| |/ /
|/| /
| |/
| |
| |
| |
| |
| | |
layer bitmap size=4294938624
Merge commit '4d2dbebf3d08209f751585d8cc367369e2f6e32f'
* commit '4d2dbebf3d08209f751585d8cc367369e2f6e32f':
fix for [1885684] E/SurfaceFlinger( 60): not enough memory for layer bitmap size=4294938624
|
| |
| |
| |
| | |
size=4294938624
|
| | |
|
| |
| |
| |
| | |
compilo doesn't complain
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
longer), client who have the buffers still mapped won't crash, btu may see garbage data
|
|\ \ |
|
| | |
| | |
| | |
| | | |
bigger screen.
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | | |
Merge commit '58ebdcc06eca06741460a7db2be4b79e3865eb88'
* commit '58ebdcc06eca06741460a7db2be4b79e3865eb88':
fix [1947273] the DimLayer causes the whole screen to update during transactions
|
| | | |
|
| | |
| | |
| | |
| | | |
optimizations, choose UPDATE_ON_DEMAND which is often more efficient.
|
| | | |
|
| | |
| | |
| | |
| | | |
we can't use a texture of 1/4th of the screen for the dim layer, because the mdp internal input resultion is alwyas integers and for very small blits of a couple pixels the scale factor can get way out of range, for instance for a 7 pixels source, the scale factor would be either 7 (7/1) or 3.5 (7/2) instead of 4 (7/1.75). This caused the mdp to fail in some cases and revert to software. we now always use a texture of the actual screen size, so the problem will never happen. This burns 300KB of pmem instead of 21KB. On devices with a larger screen we might want to use a smaller texture and tile it by hand.
|
| | | |
|