1032180 - [dolphin]No boot animation when restart the phone

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Vendcom, defect)

Description

[yang.zhao]

No boot animation when restart the system, but if you just restart the b2g, the boot animation will show.

Comment 1

[James Zhang (Spreadtrum)]

You can see boot animation with "adb shell kill <b2g pid>" commond.

Comment 2

[James Zhang (Spreadtrum)]

You can see boot animation with "adb shell kill <b2g pid>" command.

Comment 3

[Ivan Tsay (:ITsay)]

Hi Yang,

Is this one also reproducible on Flame?

Comment 4

[yang.zhao]

(In reply to Ivan Tsay (:ITsay) from comment #3)
> Hi Yang,
> 
> Is this one also reproducible on Flame?
Yes,flame also has no boot animation when restart the phone. Just a picture with the sring "T2Mobile",and then mozilla picture,the lockscreen.

Comment 5

[Ivan Tsay (:ITsay)]

Hi Vincent,

Mind if can help to take a look this bug. Thanks

Comment 6

[Vincent Liu[:vliu]]

(In reply to Ivan Tsay (:ITsay) from comment #5)
> Hi Vincent,
> 
> Mind if can help to take a look this bug. Thanks

Sure. I will take a look.

Comment 7

[Vincent Liu[:vliu]]

Here are my some tests

On Flame
1. Uses sprd bootanimation.zip file
   1.1 animation runs normally after restart the phone. (by adb reboot command)
   1.2 No animation runs if killing b2g in adb shell.

2. Uses ffos bootanimation.zip file
   1.1 animation runs normally after restart the phone. (by adb reboot command)
   1.2 animation runs normally if killing b2g in adb shell.

On dolphin
3. I got the same result for both sprd/ffos bootanimation.zip file
   3.1 No animation runs after restart the phone. (by adb reboot command)
   3.2 animation runs normally if killing b2g in adb shell.

Comment 8

[Vincent Liu[:vliu]]

b2g decides to run AnimationThread when it got GraphicBuffer to use. When the AnimationThread starts running, it unzips bootanimation.zip and copies content of .PNG file into GraphicBuffer in circular order. With assigned fps value in bootanimation.zip, usleep is used to controls the frame rate to display.

As mentioned in Comment 7, this issue happens when device is reboot by adb. More closely to observe the AnimationThread, I found that it runs well as expected when the issue happens. With checking some parameters like frame.height, frame.width or any pointer value of buffers, all of them kept their normal values and no null/zero value showed.

Another thing is when the AnimationThread runs, the device supposed to display bootAnimation. In fact, the device always kept showing splash image instead. The display of splash image may be controlled by kernel or boot. 

James, for the case I mentioned in the last, can you have more info to understand the behavior about displaying splash image? Thanks.

Comment 9

[Solomon Chiu [:schiu]]

I just pull the raw data of /dev/graphics/fb0 and look into it, while the device is booting and failed to display boot animation. The boot animation actually has being drawn into framebuffer, however it seems the framebuffer or panel driver failed to display the content in memory. The attachment is the image file that I convert from fb0 raw data.

James, can you please check if my point right?

Comment 10

[Solomon Chiu [:schiu]]

Attachment: Framebuffer content while boot animation is drawing(converted from raw data)

Comment 11

[James Zhang (Spreadtrum)]

I will check it with our framebuffer owner.

Comment 12

[Lawrence Mandel [:lmandel] (use needinfo)]

Moving to component vendcom based on comment 7.

Comment 13

[James Zhang (Spreadtrum)]

Dolphin use KK, and gecko display supports ICS/JB/KK, fb_post will trigger frame buffer display, I think we should check fb_post.

Comment 14

[James Zhang (Spreadtrum)]

I think gecko should add GonkDisplayKK.cpp for dolphin.

Comment 15

[bhavana bajaj [:bajaj]]

wayne, this is marked as POVB in which case our status flags should be set to unaffected, but this contradicts to comment #14. So is there a gecko change needed here or was there something that  was clarified offline?

Comment 16

[Keven Kuo [:kkuo]]

Hi! James, Ying,

Any update from your side? Thanks

--
Keven

Comment 17

[James Zhang (Spreadtrum)]

Framebuffer owner is working on this issue.

Comment 18

[Wayne Chang [:wchang]]

Sounds like this is POVB

Comment 19

[James Zhang (Spreadtrum)]

Our framebuffer owner said dolphin and shark only support double buffer and boot anim in gecko is single buffer.

And the origin kernel3.10 also should use double buffer.

Comment 20

[aoke]

Hi mozilla, actually, the animation can not be displayed whether the first time power on or reboot by killing b2g. Because it can not be displayed well by using 1 framebuffer.

After you reboot by killing b2g, you will see an animation refreshed by 2 framebuffer, but then you will see a static picture, which is the actual power on animation refreshed by 1 framebuffer.

so that's the same problem
1. first boot can not display animation.---------use 1 framebuffer
2. reboot by killing b2g, display an animation---use 2 framebuffer
   then keep display static picture(here is the actural power on animation)----use 1 framebuffer.

I have a question, why do you use 1 framebuffer to play animation?
When you use ramless lcd, the display control chip will continuous fetch data from framebuffer to display to keep 60fps, that means you have no chance to write data to this buffer, or you will get mass screen.

by the way, in the linux3.10 code, it will check the address offset in fbmem.c/fb_set_var/memcmp(&info->var, var, sizeof(struct fb_var_screeninfo)), so with 1 framebuffer, you can not enter this if to refresh.

Comment 21

[James Zhang (Spreadtrum)]

Attachment: bootanim.patch

Workaround for dolphin.

Comment 22

[[:fabrice] Fabrice Desré]

Comment on attachment 8458670 [details] [diff] [review]
bootanim.patch

Review of attachment 8458670 [details] [diff] [review]:
-----------------------------------------------------------------

Redirecting to mwu. Is that dolphin/tshark-only or applicable to all JB devices?

Comment 23

[Michael Wu [:mwu]]

I think we can switch to double buffering for all JB and newer devices. The reason we did single buffer before was that ICS had dedicated FB memory, and double buffering for the boot animation took too much FB memory.

Comment 24

[Michael Wu [:mwu]]

Comment on attachment 8458670 [details] [diff] [review]
bootanim.patch

Review of attachment 8458670 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/gonk/libdisplay/GonkDisplayJB.cpp
@@ -111,5 @@
> -    if (error != NO_ERROR || !mBootAnimBuffer.get()) {
> -        ALOGI("Trying to create BRGA format framebuffer");
> -        surfaceformat = HAL_PIXEL_FORMAT_BGRA_8888;
> -        mBootAnimBuffer = mAlloc->createGraphicBuffer(mWidth, mHeight, surfaceformat, usage, &error);
> -    }

This BGRA format fallback is here for a reason, and this patch removes it completely.

@@ +273,5 @@
> +    ANativeWindowBuffer* buffer = nullptr;
> +    status_t error;
> +    uint32_t usage = GRALLOC_USAGE_HW_FB | GRALLOC_USAGE_HW_RENDER | GRALLOC_USAGE_HW_COMPOSER;
> +
> +    mBootAnimBuffer[mIndex%2] = mAlloc->createGraphicBuffer(mWidth, mHeight, surfaceformat, usage, &error);

We should be able to recycle old graphic buffers, right?

::: widget/gonk/libdisplay/GonkDisplayJB.h
@@ +67,4 @@
>      hwc_display_contents_1_t* mList;
>      uint32_t mWidth;
>      uint32_t mHeight;
> +    uint32_t mIndex;

mIndex is too generic of a name.

Comment 25

[James Zhang (Spreadtrum)]

Hi Michael, how to recycle old graphic buffer? I only find "createGraphicBuffer" method and I can only set previous mBootAnimBuffer to nullptr.

Comment 26

[Michael Wu [:mwu]]

There shouldn't be anything specific you need to do - you should only need to use the previously generated graphic buffer. It can be reused.

Comment 27

[James Zhang (Spreadtrum)]

(In reply to Michael Wu [:mwu] from comment #26)
> There shouldn't be anything specific you need to do - you should only need
> to use the previously generated graphic buffer. It can be reused.

If I keep two buffer, it will cause b2g crash, we have only two frame buffer in dolphin kernel, not three buffer.
So I need alloc new buffer and free old buffer.

Comment 28

[Vincent Liu[:vliu]]

(In reply to Michael Wu [:mwu] from comment #26)
> There shouldn't be anything specific you need to do - you should only need
> to use the previously generated graphic buffer. It can be reused.

Hi Michael,

Did you mean the graphic buffer can be reused by operating methods in GraphicBuffer object? I'd tried to find possible methods like calling GraphicBuffer::reallocate(...) or GraphicBuffer::getNativeBuffer() in GonkDisplayJB::DequeueBuffer(), but they all fail to disply BootAnimation. Does there have any sample code in AOSP to reference? Thanks

Comment 29

[Wayne Chang [:wchang]]

Hi Vincent,

As you're following up, please find out if this should be fixed by partner. In such case feel free to transfer to bug to them.

Thanks

Comment 30

[Vincent Liu[:vliu]]

Attachment: WIP-double-buffering.patch

Hi James,

The attached WIP enabled double buffering. The patch worked on v1.4 flame. But for dolphin, the device kept rebooting. Can you please help to look into it in driver view? Thanks.

Comment 31

[James Zhang (Spreadtrum)]

(In reply to Vincent Liu[:vliu] from comment #30)
> Created attachment 8470433 [details] [diff] [review]
> WIP-double-buffering.patch
> 
> Hi James,
> 
> The attached WIP enabled double buffering. The patch worked on v1.4 flame.
> But for dolphin, the device kept rebooting. Can you please help to look into
> it in driver view? Thanks.

We can't keep two frame buffer. Dolphin only has 2 buffer, bootanim keeps 2 buffer, gecko can't get buffer then cause b2g crash.

Comment 32

[James Zhang (Spreadtrum)]

Vincent, please try my patch, get new frame buffer and release old frame buffer, then gecko can get buffer and no crash.

Comment 33

[Vincent Liu[:vliu]]

Attachment: bootanim-modify.patch

(In reply to James Zhang (Spreadtrum) from comment #32)
> Vincent, please try my patch, get new frame buffer and release old frame
> buffer, then gecko can get buffer and no crash.

Actually I'd tried you patch and I knew it worked to play animation after reboot the device. I also modified another WIP based on yours. Please see the attached. In this WIP, you don't have to declare two GraphicBuffer. Instead, one is enough. The WIP also works to play animation after reboot device. 

But even so, I think the point I can't figure out is I still have to create GraphicBuffer every time DequeueBuffer() is called. From the code behavior in AnimationThread:

                ANativeWindowBuffer *buf = display->DequeueBuffer();
                if (!buf) {
                    LOGW("Failed to get an ANativeWindowBuffer");
                    break;
                }

                void *vaddr;
                if (grmodule->lock(grmodule, buf->handle,
                                   GRALLOC_USAGE_SW_READ_NEVER |
                                   GRALLOC_USAGE_SW_WRITE_OFTEN |
                                   GRALLOC_USAGE_HW_FB,
                                   0, 0, width, height, &vaddr)) {
                    LOGW("Failed to lock buffer_handle_t");
                    display->QueueBuffer(buf);
                    break;
                }
            ....
            memcpy(...)
            ....
            display->QueueBuffer(buf); (call post() to framebuffer device)
            
It seems GraphicBuffer can be reused. one-GraphicBffer/double-GraphicBuffer are both work for flame.


(In reply to James Zhang (Spreadtrum) from comment #32)
> Vincent, please try my patch, get new frame buffer and release old frame
> buffer, then gecko can get buffer and no crash.

Would you please point out the exactly crash point you saw? I didn't see any null pointer or memory copy error case on dolphin.

Comment 34

[James Zhang (Spreadtrum)]

If you keep two bootanim framebuffer with WIP-double-buffering.patch, you will meet this crash, it's not device reboot, it's b2g crash and restart.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7064.7117]
0xb5174c48 in mozilla::gl::GLContextProviderEGL::CreateForWindow (aWidget=0xb298b6a0) at ../../../gecko/gfx/gl/GLContextProviderEGL.cpp:703
703	        MOZ_CRASH("Failed to create EGLContext!\n");
(gdb) bt
#0  0xb5174c48 in mozilla::gl::GLContextProviderEGL::CreateForWindow (aWidget=0xb298b6a0) at ../../../gecko/gfx/gl/GLContextProviderEGL.cpp:703
#1  0xb51d8b16 in mozilla::layers::CompositorOGL::CreateContext (this=this@entry=0xb2895160) at ../../../gecko/gfx/layers/opengl/CompositorOGL.cpp:178
#2  0xb51da63e in mozilla::layers::CompositorOGL::Initialize (this=0xb2895160) at ../../../gecko/gfx/layers/opengl/CompositorOGL.cpp:247
#3  0xb51c533c in mozilla::layers::LayerManagerComposite::Initialize (this=this@entry=0xb07aa6e0) at ../../../gecko/gfx/layers/composite/LayerManagerComposite.cpp:122
#4  0xb51d0030 in mozilla::layers::CompositorParent::InitializeLayerManager (this=this@entry=0xaf80e200, aBackendHints=...)
    at ../../../gecko/gfx/layers/ipc/CompositorParent.cpp:850
#5  0xb51d00c8 in mozilla::layers::CompositorParent::AllocPLayerTransactionParent (this=0xaf80e200, aBackendHints=..., aId=<optimized out>, 
    aTextureFactoryIdentifier=0xb1b01b34, aSuccess=0xb1b01aeb) at ../../../gecko/gfx/layers/ipc/CompositorParent.cpp:872
#6  0xb4fda690 in mozilla::layers::PCompositorParent::OnMessageReceived (this=0xaf80e200, __msg=..., __reply=@0xb1b01b90: 0x0) at PCompositorParent.cpp:828
#7  0xb4fb5b24 in mozilla::ipc::MessageChannel::DispatchSyncMessage (this=0xaf80e230, aMsg=...) at ../../../gecko/ipc/glue/MessageChannel.cpp:1067
#8  0xb4fb7936 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=<optimized out>) at ../../../gecko/ipc/glue/MessageChannel.cpp:1039
#9  0xb4fb5588 in DispatchToMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)()> (
    method=(void (mozilla::ipc::MessageChannel::*)(mozilla::ipc::MessageChannel * const)) 0xb4fb78bf <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, obj=<optimized out>, 
    arg=...) at ../../../gecko/ipc/chromium/src/base/tuple.h:383
#10 RunnableMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)(), Tuple0>::Run (this=<optimized out>) at ../../../gecko/ipc/chromium/src/base/task.h:307
#11 0xb4fb5382 in Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:383
#12 mozilla::ipc::MessageChannel::DequeueTask::Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:400
#13 0xb4fad0f8 in MessageLoop::RunTask (this=0xb1b01cb0, task=0xb1f115d0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:344
#14 0xb4fad7ba in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=...) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:352
#15 0xb4fae7ec in DoWork (this=<optimized out>) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:430
#16 MessageLoop::DoWork (this=0xb1b01cb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:409
#17 0xb4fae97c in base::MessagePumpDefault::Run (this=0xb1e4b880, delegate=0xb1b01cb0) at ../../../gecko/ipc/chromium/src/base/message_pump_default.cc:34
#18 0xb4fad086 in MessageLoop::RunInternal (this=this@entry=0xb1b01cb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:226
#19 0xb4fad138 in RunHandler (this=0xb1b01cb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:219
#20 MessageLoop::Run (this=this@entry=0xb1b01cb0) at ../../../gecko/ipc/chromium/src/base/message_loop.cc:193
#21 0xb4faf92a in base::Thread::ThreadMain (this=0xb1e38eb0) at ../../../gecko/ipc/chromium/src/base/thread.cc:162
#22 0xb4fa65dc in ThreadFunc (closure=<optimized out>) at ../../../gecko/ipc/chromium/src/base/platform_thread_posix.cc:39
#23 0xb6f2121c in __thread_entry (func=0xb4fa65d5 <ThreadFunc(void*)>, arg=0xb1e38eb0, tls=0xb1b01dd0) at bionic/libc/bionic/pthread_create.cpp:105
#24 0xb6f213b8 in pthread_create (thread_out=0xb1e38eb8, attr=<optimized out>, start_routine=0xb4fa65d5 <ThreadFunc(void*)>, arg=0x78)
    at bionic/libc/bionic/pthread_create.cpp:224

Comment 35

[thomas tsai]

Hi Peter: Can you find one to study this topic? I wonder if kernel 3.10.x and later have the similar issues. We don't have projects with kernel 3.10.x yet, but dolphin.

Comment 36

[James Zhang (Spreadtrum)]

Can we land Vincent's patch for 1.4 only?

Comment 37

[Peter Chang[:pchang]]

(In reply to James Zhang (Spreadtrum) from comment #27)
> (In reply to Michael Wu [:mwu] from comment #26)
> > There shouldn't be anything specific you need to do - you should only need
> > to use the previously generated graphic buffer. It can be reused.
> 
> If I keep two buffer, it will cause b2g crash, we have only two frame buffer
ni chiajung to check the b2g crash when has double buffer for bootanimation.
James, I'm curious why we can't reuse graphicbuffer for boot animation on dolphin but it works for flame.
> in dolphin kernel, not three buffer.
> So I need alloc new buffer and free old buffer.

Comment 38

[Peter Chang[:pchang]]

(In reply to aoke from comment #20)
> Hi mozilla, actually, the animation can not be displayed whether the first
> time power on or reboot by killing b2g. Because it can not be displayed well
> by using 1 framebuffer.
> 
> After you reboot by killing b2g, you will see an animation refreshed by 2
> framebuffer, but then you will see a static picture, which is the actual
> power on animation refreshed by 1 framebuffer.
> 
> so that's the same problem
> 1. first boot can not display animation.---------use 1 framebuffer
> 2. reboot by killing b2g, display an animation---use 2 framebuffer
>    then keep display static picture(here is the actural power on
> animation)----use 1 framebuffer.
> 
> I have a question, why do you use 1 framebuffer to play animation?
> When you use ramless lcd, the display control chip will continuous fetch
> data from framebuffer to display to keep 60fps, that means you have no
> chance to write data to this buffer, or you will get mass screen.
> 
> by the way, in the linux3.10 code, it will check the address offset in
> fbmem.c/fb_set_var/memcmp(&info->var, var, sizeof(struct
> fb_var_screeninfo)), so with 1 framebuffer, you can not enter this if to
> refresh.

aoek, I just checked our flame kernel source code and found flame also have this memcmp you mentioned above. Therefore, I don't think this is the root cause to cause this problem.

https://github.com/mozilla-b2g/codeaurora_kernel_msm/blob/t2m-flame-3.4-jb/drivers/video/fbmem.c#L967

Comment 39

[James Zhang (Spreadtrum)]

see comment 20

When you use ramless lcd, the display control chip will continuous fetch data from framebuffer to display to keep 60fps, that means you have no chance to write data to this buffer, or you will get mass screen.

Comment 40

[James Zhang (Spreadtrum)]

I think it's by spreadtrum kernel 3.10 fb design, android surface flinger always use double buffer.
And we should support ramless lcd. So we don't support singer fb buffer.

Comment 41

[Vincent Liu[:vliu]]

(In reply to James Zhang (Spreadtrum) from comment #34)
> If you keep two bootanim framebuffer with WIP-double-buffering.patch, you
> will meet this crash, it's not device reboot, it's b2g crash and restart.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 7064.7117]
> 0xb5174c48 in mozilla::gl::GLContextProviderEGL::CreateForWindow
> (aWidget=0xb298b6a0) at ../../../gecko/gfx/gl/GLContextProviderEGL.cpp:703
> 703	        MOZ_CRASH("Failed to create EGLContext!\n");
> (gdb) bt

The root cause seems to be in the following code.

        // The order of these strings must match up with the order of the enum
        // defined in GLContext.h for vendor IDs
        glVendorString = (const char *)fGetString(LOCAL_GL_VENDOR);
        if (!glVendorString)
            mInitialized = false;

http://lxr.mozilla.org/mozilla-central/source/gfx/gl/GLContext.cpp#563

glVendorString gets null causes mInitialized set to false.

Comment 42

[Chiajung Hung [:chiajung]]

(In reply to Vincent Liu[:vliu] from comment #41)
> (In reply to James Zhang (Spreadtrum) from comment #34)
> > If you keep two bootanim framebuffer with WIP-double-buffering.patch, you
> > will meet this crash, it's not device reboot, it's b2g crash and restart.
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 7064.7117]
> > 0xb5174c48 in mozilla::gl::GLContextProviderEGL::CreateForWindow
> > (aWidget=0xb298b6a0) at ../../../gecko/gfx/gl/GLContextProviderEGL.cpp:703
> > 703	        MOZ_CRASH("Failed to create EGLContext!\n");
> > (gdb) bt
> 
> The root cause seems to be in the following code.
> 
>         // The order of these strings must match up with the order of the
> enum
>         // defined in GLContext.h for vendor IDs
>         glVendorString = (const char *)fGetString(LOCAL_GL_VENDOR);
>         if (!glVendorString)
>             mInitialized = false;
> 
> http://lxr.mozilla.org/mozilla-central/source/gfx/gl/GLContext.cpp#563
> 
> glVendorString gets null causes mInitialized set to false.

This fail is because eglMakeCurrent failed. And it is in fact a out-of-memory condition:
03-05 14:44:38.950   621   670 E         : GraphicBufferAlloc::createGraphicBuffer(w=480, h=854) failed (Out of memory), handle=0x0
03-05 14:44:38.950   621   670 E BufferQueue: [FramebufferSurface] dequeueBuffer: SurfaceComposer::createGraphicBuffer failed
03-05 14:44:38.950   621   670 E [EGL-ERROR]: void __egl_platform_dequeue_buffer(egl_surface*):1854: failed to dequeue buffer from native window 0xb6a54808; err = -12, buf = 0x0,max_allowed_dequeued_buffers 1
03-05 14:44:38.950   621   670 E libEGL  : eglMakeCurrent:775 error 3003 (EGL_BAD_ALLOC)

I think a easy fix would be abandon all the preallocated buffers earlier.

eglGetString only fails while no current context.

Comment 43

[Chiajung Hung [:chiajung]]

Attachment: WIP

This one should provide better performance than allocation for each loop.
But is slightly trickier to stop the animation.

Comment 44

[Chiajung Hung [:chiajung]]

Attachment: V1

Comment 45

[Vincent Liu[:vliu]]

Chiajung seems to have a better patch for this issue. Switch the owner to him.

Comment 46

[Michael Wu [:mwu]]

Yeah, this is a better approach, but this also means the animation stops as soon as we start to initialize. Maybe we can have a buffer queue dedicated to the boot animation? We couldn't do this easily before, but it might be easy to do now on JB/KK.

Comment 47

[Chiajung Hung [:chiajung]]

(In reply to Michael Wu [:mwu] from comment #46)
> Yeah, this is a better approach, but this also means the animation stops as
> soon as we start to initialize. Maybe we can have a buffer queue dedicated
> to the boot animation? We couldn't do this easily before, but it might be
> easy to do now on JB/KK.

The old patch from Vincent tries to use such dedicated queue, but the problem is mentioned in comment 42:
It makes the EGL initilization fail because of OOM. To make his patch work, we will have to stop the animation, and kill most buffer(keep only 1) as soon as EGL starts to initialize, too.

I suspect the problem is that GRALLOC_USAGE_HW_FB usage flag may cause the gralloc module allocate memory from some small dedicated memory space. Maybe from FB driver preserved memory while boot kernel(usually 2 full size). While EGL init, it requests buffer with flag: 0x1e02, which is: 
GRALLOC_USAGE_HW_FB|GRALLOC_USAGE_HW_COMPOSER|GRALLOC_USAGE_HW_2D|GRALLOC_USAGE_HW_RENDER|GRALLOC_USAGE_SW_READ_RARELY. His patch keeps 2 such buffer and makes further allocation fail.

To get rid of OOM, we have to release all such buffer except 1 while EGL starts. To be BSP independent, we should always use at least GRALLOC_USAGE_HW_FB for BootAnimation. So the final patch would very similar to this.

NOTE that: If my patch kills all the buffer soon after EGL starts, we should observe some black screen or jumping animation, but we not. I suspect that is because HWC/FB driver still keeps the last reference of the gralloc_handle. (gralloc buffer is usually have to be refcounted in driver level)

BTW, StopAnimation does not stop animation immediately, it use pthread_join to wait it loop through 1 animation part and blocks the EGL init to wait the Animation.

Comment 48

[Michael Wu [:mwu]]

Yeah, we definitely don't want a buffer queue with GRALLOC_USAGE_HW_FB. FB memory is very limited. On JB/KK hardware, there's usually a HWC module which doesn't require GRALLOC_USAGE_HW_FB buffers. It looks like the Dolphin doesn't have that though, so that doesn't help us. I was assuming Dolphin had a hardware composer and no framebuffer.

(In reply to Chiajung Hung [:chiajung] from comment #47)
> BTW, StopAnimation does not stop animation immediately, it use pthread_join
> to wait it loop through 1 animation part and blocks the EGL init to wait the
> Animation.

At one point, we only waited for the animation to complete after gecko and gaia were basically all done loading, so the animation didn't block startup unnecessarily. But now, this is a problem..

So for now, I think we should take your approach for now. Getting a better fix is going to be much more involved. I'll try to figure out a better solution for the 2.1 branch.

Comment 49

[Michael Wu [:mwu]]

Oh, one thing though - this patch also removed the BGRA fallback that was added in bug 921369. I would ask Vincent, but his bugzilla account appears to be disabled. I think the fallback was for Flatfish, but I'm not sure. Guess we can just land and see if anything breaks..

Comment 50

[Michael Wu [:mwu]]

Comment on attachment 8472211 [details] [diff] [review]
V1

Review of attachment 8472211 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Just check this on Flame before landing if you haven't yet.

Comment 51

[Chiajung Hung [:chiajung]]

It seems Flame works. Except that the animation stops earlier. I am searching a way to avoid such condition...

Comment 52

[Michael Wu [:mwu]]

I'm not sure if there's much you can do. IIRC once the buffer queue is passed to EGL to create a window, it always holds to at least one buffer, so you then have to use gles or any layers on top of it to continue rendering. Alternately, you might be able to configure the buffer queue to store three buffers, but then we'd be unnecessarily using more memory after the animation is complete. I do want to go for closer integration with layers though. The idea is to integrate the boot animation as the top layer as soon as possible, and fade that layer away when we receive browser-ui-startup-complete.

Comment 53

[Yeojin Chung [:YeojinC]]

New test case needs to be added. There is no existing test case.

Comment 54

[Chiajung Hung [:chiajung]]

(In reply to Michael Wu [:mwu] from comment #52)
> I'm not sure if there's much you can do. IIRC once the buffer queue is
> passed to EGL to create a window, it always holds to at least one buffer, so
> you then have to use gles or any layers on top of it to continue rendering.
> Alternately, you might be able to configure the buffer queue to store three
> buffers, but then we'd be unnecessarily using more memory after the
> animation is complete. I do want to go for closer integration with layers
> though. The idea is to integrate the boot animation as the top layer as soon
> as possible, and fade that layer away when we receive
> browser-ui-startup-complete.

I tried many tricks but no luck. 

The best solution would be switch to EGL render once EGL initialized. That should not very hard if we can get the CompositorThread(underlying pthread) from Compositor, we should be able to switch to GL rendering smoothly. But to stop the animation would be very tricky, too. Since it is a standalone library, it would be hard to receive any DOM event or any Gecko event.

To use LayerSystem here would be very hard as libdisplay is a standalone library, so use any Gecko classes should be very hard.

Comment 55

[Peter Chang[:pchang]]

(In reply to Michael Wu [:mwu] from comment #50)
> Comment on attachment 8472211 [details] [diff] [review]
> V1
> 
> Review of attachment 8472211 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good. Just check this on Flame before landing if you haven't yet.

(In reply to Chiajung Hung [:chiajung] from comment #51)
> It seems Flame works. Except that the animation stops earlier. I am
> searching a way to avoid such condition...

I would prefer to land this patch for 1.4 first and create another follow up bug to fix boot animation for dolphin in master.

Comment 56

[KTucker [:KTucker][Inactive 3/4/2016]]

Test case added to moztrap:

https://moztrap.mozilla.org/manage/case/14387/

Comment 57

[Chiajung Hung [:chiajung]]

Attachment: V1, final

Add reviewer info into commit log, carry r+.
Try ticket:
https://tbpl.mozilla.org/?tree=Try&rev=ead230004971

Comment 58

[Ryan VanderMeulen [:RyanVM]]

(In reply to Chiajung Hung [:chiajung] from comment #57)
> https://tbpl.mozilla.org/?tree=Try&rev=ead230004971

Why did you build and test this on all platforms when the files you touched are only built on Gonk? We have massive backlogs on Try and pushes like these are a big contributor to that. Please be more considerate of your co-workers in the resources you're using.

https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices

Comment 59

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/bcb2ad74082d

More to the point, even B2G ICS builds/tests were a waste for this. The *only* useful results you can get for a TBPL run for this patch was B2G JB builds. The other 300+ hours of builds and tests told you nothing.

Comment 60

[Chiajung Hung [:chiajung]]

Sorry for inconvient, I thought we have a landing policy for such bug says: you have to test all before checkin-needed. I will be more careful about the try selection next time.

Comment 61

[Ryan VanderMeulen [:RyanVM]]

We require a link to a recent Try run, but we leave it up to the developer to decide which builds and tests are sufficient for their patches :)

Comment 62

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/bcb2ad74082d

Comment 63

[Chiajung Hung [:chiajung]]

This is for 1.4 branch only, please check to 1.4 branch only

Comment 64

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a1e4426348f6

Comment 65

[Shally Li（leave from Mozilla）]

This issue has been successfully verified on Flame v2.1.
See attachment: verified_v2.1.mp4.
Reproduce rate: 0/5.

STR:
1.Restart device or Power on device.
**Boot animation will display.

Flame 2.1 build:
Gaia-Rev        17c7ad2e4919a994f0844239b483116090412dee
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/39dfb662c82a
Build-ID        20141225001203
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141225.035108
FW-Date         Thu Dec 25 03:51:19 EST 2014
Bootloader      L1TC00011880

Comment 66

[Shally Li（leave from Mozilla）]

Attachment: verified_2.1.mp4