RGBA16F bitmaps used as an SkBitmapShader would not set the hasLinearTexture
flag in the program description, causing a shader to be generated without
the proper opto-electronic transfer function.
Bug: 35482305
Test: bit -t CtsUiRenderingTestCases:android.uirendering.cts.testclasses.Rgba16fTests
Change-Id: I23354f8189a6b27b677eac9df82677e91282a31d
Bug: 34206215
Test: hwui unit tests passing, manual test of TextureView video playback
Always flush renderstate to the GlLayer's texture, regardless of
whether updateTexImage has ever been called.
Change-Id: I3974dce9d90633a0299e6bc4259b76c622717c90
Test: UiRendering CTS SweepTests with picture mode turned on and
drawBitmapMesh turned off (it's not implemented yet).
This should fix BUG:34306056, and part of BUG:34871089 (the drawArc part
of SweepTests in picture mode).
BUG:34306056
BUG:34871089
Change-Id: I8fdcf72ddb4a0bfccedfd7e4e374a1ec5df17d75
(cherry picked from commit 538b6359cf81b14322141089161f20291295d6d3)
Implement "dump displaylist" button in hierarchyviewer for skia
pipelines.
Test: ran hierarchyviewer for all pipelines.
bug: 34819877
Change-Id: Ifeb578260f636cb67268f9f9259e7318bf7de453
RGBA16F bitmaps are always encoded in linear space, which means we must
apply the opto-electronic transfer function before we can render them
in the framebuffer.
Since our linear bitmaps are assumed to be scRGB, values can be negative.
The OETF is a slightly modified sRGB OETF:
sign(x) * OETF_sRGB(abs(x))
This effectively mirrors the OETF over the negative domain.
This CL also removes the "optimized" shader generation path. With
current compilers, the optimized path doesn't do anything of value
and makes ProgramCache difficult to maintain. Shader compilers inline
everything and are really good at folding expressions and removing
unused code.
Bug: 32984164
Test: CtsUiRenderingTestCases
Change-Id: Ieb458ad53574e3a8959aa6bccbbd2d1fe203cbc5
Test: manual; ran hwuimacro -c 10000 and started a systrace
while it was running. verified trace tags showed up as
expected
Change-Id: Iedc20c6825e77b76ad79660512b627201f61969f
Bug: 34809371
Test: manual
New benchmark uses several levels of overdraw from just shadows to benchmark
shadow shader performance.
Tessellation workload is minimal, due to simple rect caster shape.
Change-Id: I760961e6d48d44ca61f4e8ebca5760175af34953
Fix a deadlock with Skia pipelines, caused by calling
Bitmap::getSkBitmap from render thread.
Test: built and booted an image. Ran recent apps activity.
bug: 35060578
bug: 34926691
Change-Id: Iaf7957b955d938b722b153d72ad832ae5d50e86f
- libRS.so is not directly used. It is accessed by libRScpp.so.
Test: mm, and boot-up test on sailfish
Change-Id: I5742d2ee3b34ef09bcb997524408affce1ace8fd
(cherry picked from commit 629fd3d48ba1dbedc6e84e91a26f72fb1fba0e22)
Use new Skia DrawShadow API to draw shadows and remove unused code
from HWUI.
Test: Built and ran shadow macrobench tests.
Change-Id: Ief86b03b7348367f8bae8c212d64d5a545eebaeb
As of O, gradients are interpolated in linear space. This unfortunately
affects applications that were expecting a certain behavior for the
alpha ramp. This change attempts to get the best of both world: better
color interpolation (in linear space) and the old alpha interpolation
(in gamma space). This is achieved by applying the electro-optical
transfer function to the alpha channel; an idea so wrong it would
make any graphics programmer worth his salt weep in disgust.
As abhorrent this idea might be to me, it also acts as a faint
beacon of hope admist the unfathomable darkness that is Android's
color management.
And if you allow me another misguided metaphor, this change
represents the flotsam I can cling onto in the hope to one day
reach the bountiful shores of linear blending and accurate color
management. Would this change not fix the distress caused by its
predecessors, I will have no choice but bow my head in shame until
the day I can finally devise an infallible plan.
Bug: 33010587
Test: CtsUiRenderingTestCases
Change-Id: I5397fefd7944413f2c820e613a5cba50579d4dd5
Bug: 34809371
Test: manual
New benchmark uses several levels of overdraw from just shadows to benchmark
shadow shader performance.
Tessellation workload is minimal, due to simple rect caster shape.
Change-Id: I572476bd54e04566851f39027ada7254597b37f8
So trying to mimic what the EglManager does in the fence call.
Technically there are two logical queues I could wait on for the device,
the graphics queue and the present queue. Waiting on the device waits
for both these queues to finish. It wasn't obvious to me if the EGL was
waiting for just graphics work or both queues, so I went for both (by
waiting on device). However, so far every device we've seen in Vulkan
has the present and graphics queue combined on the physical device so
waiting for one or both should really be different.
Test: Manual ran macrobench in skiavk and more realistic values compared
to not waiting for gpu.
Change-Id: I17cde70c677a9ad1b6bf9bc9ca4fd5f8f3b807e3
