994590 - [Tarako][Graphics][Homescreen] App icon is changed to be black in animation shake while a user scroll home screen page in app managed mode.

Status: RESOLVED DUPLICATE of bug 1012551

(Core :: Graphics, defect)

Description

[[e-mail], [e-mail]]

STR:

Create favourite links via Everything.me.
Enter any topic or keyword in “I’m thinking of…”
Add the topic or keyword to create favourite icon via yellow star
Long press an app icon in home screen. Then, it will run into app icon managed mode.
Drag an app icon to home screen page 1 or 2.
Scroll home screen page 1 <-> 2 <-> 3

Expected result:
App icons are displayed in normally.

Actual result:
One of an app icon is changed to be black.

Build version:

Gaia      47b4b681eb0f5e6dcf86a2f35ce51869d8460249
Gecko     f6893b30657b8b8208a5c9de8b6b96b9a09a3fb1
BuildID   20140410042058
Version   28.1
ro.build.version.incremental=250
ro.build.date=Thu Apr 10 04:16:35 CST 2014

Build: sp6821a_gonk-userdebug 4.0.4.0.4.0.4 OPENMASTER 250 test-keys

Comment 1

[[e-mail], [e-mail]]

Attachment: 20140406_170204.jpg

screen shot

Comment 2

[[e-mail], [e-mail]]

Attachment: dmesg_black_icon.txt

Comment 3

[[e-mail], [e-mail]]

Attachment: IMG_1101.MOV

Please reference the record. It's easy to understand the reproduced steps.

Comment 4

[[e-mail], [e-mail]]

Got the error log while we're scrolling home screen in app icon managed mode. Even if we cannot reproduce the issue, the log is still happened.

01-02 03:17:32.210  5238  5238 E GeckoConsole: [JavaScript Warning: "Error in parsing value for 'transition'.  Declaration dropped." {file: "app://homescreen.gaiamobile.org/index.html#rootMon%20Jan%2002%202012%2003:17:22%20GMT+0000%20(UTC)" line: 0 column: 15 source: "-moz-transform -1.7976931348623157e+308ms ease"}]
01-02 03:17:32.210  5238  5238 E GeckoConsole: [JavaScript Warning: "Error in parsing value for 'transition'.  Declaration dropped." {file: "app://homescreen.gaiamobile.org/index.html#rootMon%20Jan%2002%202012%2003:17:22%20GMT+0000%20(UTC)" line: 0 column: 15 source: "-moz-transform -1.7976931348623157e+308ms ease"}]

Comment 5

[[e-mail], [e-mail]]

Hi Peter, the issue is able to reproduce via PVT build on Tarako. But it cannot be reproduced on Unagi with build v1.3t.

I try to use app manager for debugging the black app icon. Once I focus on the <image> tag via inspector, the black icon will be disappear 1 second. Then, the black icon is appeared again. But I don't see any change in CSS style sheet. I suspect it's a graphics issue. Could you please help to find someone looking the graphics issue? Thanks.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

Cool animation duration: -1.7976931348623157e+308ms

From comment 4, though, it sounds like that may be unrelated if those log messages always happen even if the bug here does not reproduce.

What is the reproduction rate for this bug?

Comment 7

[[e-mail], [e-mail]]

(In reply to Ben Kelly [:bkelly] from comment #6)
> Cool animation duration: -1.7976931348623157e+308ms
> 
> From comment 4, though, it sounds like that may be unrelated if those log
> messages always happen even if the bug here does not reproduce.
> 
Yes, just for reference.
> What is the reproduction rate for this bug?
The reproduction rate is 1/5.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: 2014-04-10-10-28-40.png

I was able to reproduce this by moving a collection icon versus a regular icon.  I also see a lot of bizarre behavior such as when I long tapped on the email icon it stuck and the homescreen kept on trying to go to the far right screen.

I'll have to try to break it down into separate bugs.

Gaia      022b03a57e4b8c697a6066961e7581d07eb99305
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/b9dba13d50a9
BuildID   20140410004001
Version   28.1
ro.build.version.incremental=eng.cltbld.20140410.040335
ro.build.date=Thu Apr 10 04:03:42 EDT 2014
Tarako

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.3T+ for broken display on icon

Comment 10

[Joe Cheng [:jcheng] (please needinfo)]

QAWANTED, can we have QA to understand if there is a simpler STR to reproduce this? triage team tend to minus this if there is no simpler STR 
thanks

Comment 11

[Jason Smith [:jsmith]]

(In reply to Joe Cheng [:jcheng] from comment #10)
> QAWANTED, can we have QA to understand if there is a simpler STR to
> reproduce this? triage team tend to minus this if there is no simpler STR 
> thanks

I wouldn't call the STR in comment 0 entirely complex. All the reporter is doing here is adding an e.me collection to the homescreen, dragging it, and switching screens. That's actually likely a common workflow for a user if they are trying to add something new to the homescreen & organizing it.

Comment 12

[Peter Chang[:pchang]]

(In reply to Ian Liu [:ianliu] from comment #7)
> (In reply to Ben Kelly [:bkelly] from comment #6)
> > Cool animation duration: -1.7976931348623157e+308ms
> > 
> > From comment 4, though, it sounds like that may be unrelated if those log
> > messages always happen even if the bug here does not reproduce.
> > 
> Yes, just for reference.
> > What is the reproduction rate for this bug?
> The reproduction rate is 1/5.

I just drag one icon into a new page and still can reproduce the black icon issue.
After checking in compositor side, the buffer which contains the img holds the correct data.

But it looks like it has problem to upload or draw this img buffer for display.

Comment 13

[Peter Chang[:pchang]]

I didn't see any gl error after texture uploading.

Comment 14

[yang.zhao]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #8)
> Created attachment 8404844 [details]
> 2014-04-10-10-28-40.png
> 
> I was able to reproduce this by moving a collection icon versus a regular
> icon.  I also see a lot of bizarre behavior such as when I long tapped on
> the email icon it stuck and the homescreen kept on trying to go to the far
> right screen.
I also met this issue twice,the email was on the third page,and you couldn't sweep to the first or second page,but I haven't found the STR.
> 
> I'll have to try to break it down into separate bugs.
> 
> Gaia      022b03a57e4b8c697a6066961e7581d07eb99305
> Gecko    
> https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/b9dba13d50a9
> BuildID   20140410004001
> Version   28.1
> ro.build.version.incremental=eng.cltbld.20140410.040335
> ro.build.date=Thu Apr 10 04:03:42 EDT 2014
> Tarako

Comment 15

[yang.zhao]

(In reply to peter chang[:pchang][:peter] from comment #13)
> I didn't see any gl error after texture uploading.
Sometimes the black square doesn't always black,I met once that the black square and the image turned up alternately in animation shake.

Comment 16

[Peter Chang[:pchang]]

(In reply to yang.zhao from comment #15)
> (In reply to peter chang[:pchang][:peter] from comment #13)
> > I didn't see any gl error after texture uploading.
> Sometimes the black square doesn't always black,I met once that the black
> square and the image turned up alternately in animation shake.

I found a easy way to reproduce this bug.
Drag one icon to one new page and repeat to long press that icon and sometimes the black icon happens.

With above reproduce steps, re-upload the texture again could solve the problem after black icon displayed. It maybe related to GPU driver. The next step is to bind the texture to FBO and read back to see the content.

Comment 17

[Peter Chang[:pchang]]

Attachment: easy way to reproduce black icon

Attached the screenshot that how I reproduce this issue quickly.

a. Drag one icon to new page, so you only have five icons in one pages
b. Long press the first icon and will see the animation
c. Check black icon happens or not
d. Click anywhere of homescreen to stop the animation
e. repeat b until black icon happens

With above method, I could reproduce black icons with 10 times.

Comment 18

[Peter Chang[:pchang]]

Attachment: debug patch - re-upload texture when black icon happens

During app managed animation, each icon will generate its own texture and upload its own image buffer to GPU by TexImage2D API. After texture upload finished, compositor only binds related texture to GPU(no upload anymore) for composition.

  When the black icon happened, I confirmed the image buffer that used to upload was valid. But it displayed black icon during the whole animation process.

  In order to figure out the problem, I wrote this debug patch to re-upload texture. When the texture reupload, the default behavior is calling TexSubImage2D API which doesn't try to allocate new buffer. There is another property to switch to TexImage2D API which will try to allocate buffer. 

  The black icon could be fixed when texture reupload with TexSubImage2D API

Therefore, I think this issue is related to low memory which causes GPU fail to allocate texture buffer but there is no GL error return.

  James, please help to reproduce this issue on your side and discuss with mali GPU team if needs.

[How to use]
a. Reproduce until black icon happens
b. Re-upload by "adb shell setprop debug.gfx.upload 5"
   P.S. 5 is the icon number in one page that force upload texture for every icon.
c. See the re-upload log from logcat
d. Switch to TexImage2D API by "adb shell setprop debug.gfx.sub 0"
e. Re-upload by "adb shell setprop debug.gfx.upload 5"

[Log example]
I/Gecko   ( 1258): pchang UploadImageDataToTexture texture 22 textureUnit 0x000084c0 call TexSubImage2D
I/Gecko   ( 1258): pchang UploadImageDataToTexture texture 23 textureUnit 0x000084c0 call TexSubImage2D

I/Gecko   ( 1258): pchang UploadImageDataToTexture texture 24 textureUnit 0x000084c0 call TexImage2D
I/Gecko   ( 1258): pchang UploadImageDataToTexture texture 20 textureUnit 0x000084c0 call TexImage2D

Comment 19

[James Zhang (Spreadtrum)]

Is it LMK/OOM issue. I found sometimes Compositor or b2g can't alloc memory and trigger LMK/OOM.

04-19 08:29:20.143 <4>0[41218.294573] Compositor invoked oom-killer: gfp_mask=0x286d2, order=0, oom_adj=0, oom_score_adj=0
04-19 08:29:20.143 <4>0[41218.294657] Backtrace: 
04-19 08:29:20.143 <4>0[41218.294714] [<c4537ad8>] (dump_backtrace+0x0/0x110) from [<c4889f0c>] (dump_stack+0x18/0x1c)
04-19 08:29:20.143 <4>0[41218.294780]  r7:000286d2 r6:000286d2 r5:00000000 r4:c66a8000
04-19 08:29:20.143 <4>0[41218.294857] [<c4889ef4>] (dump_stack+0x0/0x1c) from [<c4599464>] (dump_header.clone.1+0x7c/0xac)
04-19 08:29:20.143 <4>0[41218.294933] [<c45993e8>] (dump_header.clone.1+0x0/0xac) from [<c45994d4>] (oom_kill_process.clone.0+0x40/0x26c)
04-19 08:29:20.143 <4>0[41218.295008]  r6:00000000 r5:00000169 r4:c67df0e0
04-19 08:29:20.143 <4>0[41218.295070] [<c4599494>] (oom_kill_process.clone.0+0x0/0x26c) from [<c45999b4>] (out_of_memory+0x2b4/0x3a0)
04-19 08:29:20.143 <4>0[41218.295153] [<c4599700>] (out_of_memory+0x0/0x3a0) from [<c459cfb4>] (__alloc_pages_nodemask+0x484/0x598)
04-19 08:29:20.143 <4>0[41218.295258] [<c459cb30>] (__alloc_pages_nodemask+0x0/0x598) from [<bf003ed4>] (os_allocate+0x11c/0x38c [ump])
04-19 08:29:20.143 <4>0[41218.295363] [<bf003db8>] (os_allocate+0x0/0x38c [ump]) from [<bf002b08>] (_ump_ukk_allocate+0x1f4/0x380 [ump])
04-19 08:29:20.143 <4>0[41218.295471] [<bf002914>] (_ump_ukk_allocate+0x0/0x380 [ump]) from [<bf0057cc>] (ump_secure_id_from_phys_blocks_wrapper+0x308/0x450 [ump])
04-19 08:29:20.143 <4>0[41218.295594] [<bf0056e0>] (ump_secure_id_from_phys_blocks_wrapper+0x21c/0x450 [ump]) from [<bf003754>] (ump_file_ioctl+0x11c/0x238 [ump])
04-19 08:29:20.143 <4>0[41218.295683]  r8:c4534244 r7:0000000c r6:c0109002 r5:457a5908 r4:457a5908
04-19 08:29:20.143 <4>0[41218.295784] [<bf003638>] (ump_file_ioctl+0x0/0x238 [ump]) from [<c45d7eb0>] (do_vfs_ioctl+0x540/0x5c4)
04-19 08:29:20.143 <4>0[41218.295854]  r7:0000000c r6:c68d86a8 r5:c649ec00 r4:457a5908
04-19 08:29:20.143 <4>0[41218.295929] [<c45d7970>] (do_vfs_ioctl+0x0/0x5c4) from [<c45d7f74>] (sys_ioctl+0x40/0x64)
04-19 08:29:20.143 <4>0[41218.295991]  r9:c66a8000 r8:c4534244 r7:0000000c r6:c0109002 r5:457a5908
04-19 08:29:20.143 <4>0[41218.296061] r4:c649ec00
04-19 08:29:20.143 <4>0[41218.296102] [<c45d7f34>] (sys_ioctl+0x0/0x64) from [<c4534040>] (ret_fast_syscall+0x0/0x5c)
04-19 08:29:20.143 <4>0[41218.296166]  r7:00000036 r6:00000004 r5:00090000 r4:457a5924

Comment 20

[Peter Chang[:pchang]]

(In reply to James Zhang from comment #19)
> Is it LMK/OOM issue. I found sometimes Compositor or b2g can't alloc memory
> and trigger LMK/OOM.
> 
> 04-19 08:29:20.143 <4>0[41218.294573] Compositor invoked oom-killer:
> gfp_mask=0x286d2, order=0, oom_adj=0, oom_score_adj=0
> 04-19 08:29:20.143 <4>0[41218.294657] Backtrace: 
> 04-19 08:29:20.143 <4>0[41218.294714] [<c4537ad8>]
> (dump_backtrace+0x0/0x110) from [<c4889f0c>] (dump_stack+0x18/0x1c)
> 04-19 08:29:20.143 <4>0[41218.294780]  r7:000286d2 r6:000286d2 r5:00000000
> r4:c66a8000
> 04-19 08:29:20.143 <4>0[41218.294857] [<c4889ef4>] (dump_stack+0x0/0x1c)
> from [<c4599464>] (dump_header.clone.1+0x7c/0xac)
> 04-19 08:29:20.143 <4>0[41218.294933] [<c45993e8>]
> (dump_header.clone.1+0x0/0xac) from [<c45994d4>]
> (oom_kill_process.clone.0+0x40/0x26c)
> 04-19 08:29:20.143 <4>0[41218.295008]  r6:00000000 r5:00000169 r4:c67df0e0
> 04-19 08:29:20.143 <4>0[41218.295070] [<c4599494>]
> (oom_kill_process.clone.0+0x0/0x26c) from [<c45999b4>]
> (out_of_memory+0x2b4/0x3a0)
> 04-19 08:29:20.143 <4>0[41218.295153] [<c4599700>] (out_of_memory+0x0/0x3a0)
> from [<c459cfb4>] (__alloc_pages_nodemask+0x484/0x598)
> 04-19 08:29:20.143 <4>0[41218.295258] [<c459cb30>]
> (__alloc_pages_nodemask+0x0/0x598) from [<bf003ed4>]
> (os_allocate+0x11c/0x38c [ump])
> 04-19 08:29:20.143 <4>0[41218.295363] [<bf003db8>] (os_allocate+0x0/0x38c
> [ump]) from [<bf002b08>] (_ump_ukk_allocate+0x1f4/0x380 [ump])
> 04-19 08:29:20.143 <4>0[41218.295471] [<bf002914>]
> (_ump_ukk_allocate+0x0/0x380 [ump]) from [<bf0057cc>]
> (ump_secure_id_from_phys_blocks_wrapper+0x308/0x450 [ump])
> 04-19 08:29:20.143 <4>0[41218.295594] [<bf0056e0>]
> (ump_secure_id_from_phys_blocks_wrapper+0x21c/0x450 [ump]) from [<bf003754>]
> (ump_file_ioctl+0x11c/0x238 [ump])
> 04-19 08:29:20.143 <4>0[41218.295683]  r8:c4534244 r7:0000000c r6:c0109002
> r5:457a5908 r4:457a5908
> 04-19 08:29:20.143 <4>0[41218.295784] [<bf003638>] (ump_file_ioctl+0x0/0x238
> [ump]) from [<c45d7eb0>] (do_vfs_ioctl+0x540/0x5c4)
> 04-19 08:29:20.143 <4>0[41218.295854]  r7:0000000c r6:c68d86a8 r5:c649ec00
> r4:457a5908
> 04-19 08:29:20.143 <4>0[41218.295929] [<c45d7970>] (do_vfs_ioctl+0x0/0x5c4)
> from [<c45d7f74>] (sys_ioctl+0x40/0x64)
> 04-19 08:29:20.143 <4>0[41218.295991]  r9:c66a8000 r8:c4534244 r7:0000000c
> r6:c0109002 r5:457a5908
> 04-19 08:29:20.143 <4>0[41218.296061] r4:c649ec00
> 04-19 08:29:20.143 <4>0[41218.296102] [<c45d7f34>] (sys_ioctl+0x0/0x64) from
> [<c4534040>] (ret_fast_syscall+0x0/0x5c)
> 04-19 08:29:20.143 <4>0[41218.296166]  r7:00000036 r6:00000004 r5:00090000
> r4:457a5924

I didn't see the LMK/OOM log from /proc/kmsg when issue happened. James, are you able to reproduce this issue on your side? Please provide your feedback about comment 18.

Comment 21

[Chiajung Hung [:chiajung]]

(In reply to James Zhang from comment #19)
> Is it LMK/OOM issue. I found sometimes Compositor or b2g can't alloc memory
> and trigger LMK/OOM.
> 
> 04-19 08:29:20.143 <4>0[41218.294573] Compositor invoked oom-killer:
> gfp_mask=0x286d2, order=0, oom_adj=0, oom_score_adj=0
> 04-19 08:29:20.143 <4>0[41218.294657] Backtrace: 
> 04-19 08:29:20.143 <4>0[41218.294714] [<c4537ad8>]
> (dump_backtrace+0x0/0x110) from [<c4889f0c>] (dump_stack+0x18/0x1c)
> 04-19 08:29:20.143 <4>0[41218.294780]  r7:000286d2 r6:000286d2 r5:00000000
> r4:c66a8000
> 04-19 08:29:20.143 <4>0[41218.294857] [<c4889ef4>] (dump_stack+0x0/0x1c)
> from [<c4599464>] (dump_header.clone.1+0x7c/0xac)
> 04-19 08:29:20.143 <4>0[41218.294933] [<c45993e8>]
> (dump_header.clone.1+0x0/0xac) from [<c45994d4>]
> (oom_kill_process.clone.0+0x40/0x26c)
> 04-19 08:29:20.143 <4>0[41218.295008]  r6:00000000 r5:00000169 r4:c67df0e0
> 04-19 08:29:20.143 <4>0[41218.295070] [<c4599494>]
> (oom_kill_process.clone.0+0x0/0x26c) from [<c45999b4>]
> (out_of_memory+0x2b4/0x3a0)
> 04-19 08:29:20.143 <4>0[41218.295153] [<c4599700>] (out_of_memory+0x0/0x3a0)
> from [<c459cfb4>] (__alloc_pages_nodemask+0x484/0x598)
> 04-19 08:29:20.143 <4>0[41218.295258] [<c459cb30>]
> (__alloc_pages_nodemask+0x0/0x598) from [<bf003ed4>]
> (os_allocate+0x11c/0x38c [ump])
> 04-19 08:29:20.143 <4>0[41218.295363] [<bf003db8>] (os_allocate+0x0/0x38c
> [ump]) from [<bf002b08>] (_ump_ukk_allocate+0x1f4/0x380 [ump])
> 04-19 08:29:20.143 <4>0[41218.295471] [<bf002914>]
> (_ump_ukk_allocate+0x0/0x380 [ump]) from [<bf0057cc>]
> (ump_secure_id_from_phys_blocks_wrapper+0x308/0x450 [ump])
> 04-19 08:29:20.143 <4>0[41218.295594] [<bf0056e0>]
> (ump_secure_id_from_phys_blocks_wrapper+0x21c/0x450 [ump]) from [<bf003754>]
> (ump_file_ioctl+0x11c/0x238 [ump])
> 04-19 08:29:20.143 <4>0[41218.295683]  r8:c4534244 r7:0000000c r6:c0109002
> r5:457a5908 r4:457a5908
> 04-19 08:29:20.143 <4>0[41218.295784] [<bf003638>] (ump_file_ioctl+0x0/0x238
> [ump]) from [<c45d7eb0>] (do_vfs_ioctl+0x540/0x5c4)
> 04-19 08:29:20.143 <4>0[41218.295854]  r7:0000000c r6:c68d86a8 r5:c649ec00
> r4:457a5908
> 04-19 08:29:20.143 <4>0[41218.295929] [<c45d7970>] (do_vfs_ioctl+0x0/0x5c4)
> from [<c45d7f74>] (sys_ioctl+0x40/0x64)
> 04-19 08:29:20.143 <4>0[41218.295991]  r9:c66a8000 r8:c4534244 r7:0000000c
> r6:c0109002 r5:457a5908
> 04-19 08:29:20.143 <4>0[41218.296061] r4:c649ec00
> 04-19 08:29:20.143 <4>0[41218.296102] [<c45d7f34>] (sys_ioctl+0x0/0x64) from
> [<c4534040>] (ret_fast_syscall+0x0/0x5c)
> 04-19 08:29:20.143 <4>0[41218.296166]  r7:00000036 r6:00000004 r5:00090000
> r4:457a5924

Even if it is an OOM syndrome, the driver have to report GL_OUT_OF_MEMORY(0x0505) while it occurs.
However, we can not catch it from GL driver.

Comment 22

[James Zhang (Spreadtrum)]

(In reply to Chiajung Hung [:chiajung] from comment #21)
> (In reply to James Zhang from comment #19)
> > Is it LMK/OOM issue. I found sometimes Compositor or b2g can't alloc memory
> > and trigger LMK/OOM.
> > 
> > 04-19 08:29:20.143 <4>0[41218.294573] Compositor invoked oom-killer:
> > gfp_mask=0x286d2, order=0, oom_adj=0, oom_score_adj=0
> > 04-19 08:29:20.143 <4>0[41218.294657] Backtrace: 
> > 04-19 08:29:20.143 <4>0[41218.294714] [<c4537ad8>]
> > (dump_backtrace+0x0/0x110) from [<c4889f0c>] (dump_stack+0x18/0x1c)
> > 04-19 08:29:20.143 <4>0[41218.294780]  r7:000286d2 r6:000286d2 r5:00000000
> > r4:c66a8000
> > 04-19 08:29:20.143 <4>0[41218.294857] [<c4889ef4>] (dump_stack+0x0/0x1c)
> > from [<c4599464>] (dump_header.clone.1+0x7c/0xac)
> > 04-19 08:29:20.143 <4>0[41218.294933] [<c45993e8>]
> > (dump_header.clone.1+0x0/0xac) from [<c45994d4>]
> > (oom_kill_process.clone.0+0x40/0x26c)
> > 04-19 08:29:20.143 <4>0[41218.295008]  r6:00000000 r5:00000169 r4:c67df0e0
> > 04-19 08:29:20.143 <4>0[41218.295070] [<c4599494>]
> > (oom_kill_process.clone.0+0x0/0x26c) from [<c45999b4>]
> > (out_of_memory+0x2b4/0x3a0)
> > 04-19 08:29:20.143 <4>0[41218.295153] [<c4599700>] (out_of_memory+0x0/0x3a0)
> > from [<c459cfb4>] (__alloc_pages_nodemask+0x484/0x598)
> > 04-19 08:29:20.143 <4>0[41218.295258] [<c459cb30>]
> > (__alloc_pages_nodemask+0x0/0x598) from [<bf003ed4>]
> > (os_allocate+0x11c/0x38c [ump])
> > 04-19 08:29:20.143 <4>0[41218.295363] [<bf003db8>] (os_allocate+0x0/0x38c
> > [ump]) from [<bf002b08>] (_ump_ukk_allocate+0x1f4/0x380 [ump])
> > 04-19 08:29:20.143 <4>0[41218.295471] [<bf002914>]
> > (_ump_ukk_allocate+0x0/0x380 [ump]) from [<bf0057cc>]
> > (ump_secure_id_from_phys_blocks_wrapper+0x308/0x450 [ump])
> > 04-19 08:29:20.143 <4>0[41218.295594] [<bf0056e0>]
> > (ump_secure_id_from_phys_blocks_wrapper+0x21c/0x450 [ump]) from [<bf003754>]
> > (ump_file_ioctl+0x11c/0x238 [ump])
> > 04-19 08:29:20.143 <4>0[41218.295683]  r8:c4534244 r7:0000000c r6:c0109002
> > r5:457a5908 r4:457a5908
> > 04-19 08:29:20.143 <4>0[41218.295784] [<bf003638>] (ump_file_ioctl+0x0/0x238
> > [ump]) from [<c45d7eb0>] (do_vfs_ioctl+0x540/0x5c4)
> > 04-19 08:29:20.143 <4>0[41218.295854]  r7:0000000c r6:c68d86a8 r5:c649ec00
> > r4:457a5908
> > 04-19 08:29:20.143 <4>0[41218.295929] [<c45d7970>] (do_vfs_ioctl+0x0/0x5c4)
> > from [<c45d7f74>] (sys_ioctl+0x40/0x64)
> > 04-19 08:29:20.143 <4>0[41218.295991]  r9:c66a8000 r8:c4534244 r7:0000000c
> > r6:c0109002 r5:457a5908
> > 04-19 08:29:20.143 <4>0[41218.296061] r4:c649ec00
> > 04-19 08:29:20.143 <4>0[41218.296102] [<c45d7f34>] (sys_ioctl+0x0/0x64) from
> > [<c4534040>] (ret_fast_syscall+0x0/0x5c)
> > 04-19 08:29:20.143 <4>0[41218.296166]  r7:00000036 r6:00000004 r5:00090000
> > r4:457a5924
> 
> Even if it is an OOM syndrome, the driver have to report
> GL_OUT_OF_MEMORY(0x0505) while it occurs.
> However, we can not catch it from GL driver.

Loop Ying, please contact our GPU team.

Comment 23

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Here is another black screen problem at:
https://bugzilla.mozilla.org/show_bug.cgi?id=989847#c36
If I re-bind the EGLImage again in that case, the black screen is recovered.

Comment 24

[James Zhang (Spreadtrum)]

Andrew's comment, 
Please check if glDeleteTexture is called after upload. In my opinion, once a texture is uploaded to OpenGL. It is OpenGL's responsibility to make it persistent.

Comment 25

[Peter Chang[:pchang]]

(In reply to James Zhang from comment #24)
> Andrew's comment, 
> Please check if glDeleteTexture is called after upload. In my opinion, once
> a texture is uploaded to OpenGL. It is OpenGL's responsibility to make it
> persistent.

No, we won't invoke glDeleteTetxture because the TextureImageEGL is hold[1] during the animation process.
http://dxr.mozilla.org/mozilla-central/source/gfx/gl/TextureImageEGL.cpp#93

If we do the call, it should happen on every device but we only reproduce this issue on tarako.

Comment 26

[James Zhang (Spreadtrum)]

Jason will ask gpu team to support.

Comment 27

[James Zhang (Spreadtrum)]

Andrew's comment in spreadtrum bugzilla.

http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=298315

I believe there is something wrong inside FFOS.

There are many icons show on the desktop in this case. Each icon is represented by a texture object. After long press the icon, the icon will become shaking. During the drag and drop process, I found the texture object corresponding to each icon will be destroyed at first. And then be recreated again and the icon image is uploaded again. If the re-uploading failed or is forgotten, the texture object will be an empty texture and a black block will show on the desktop.

In general, OpenGL ES will keep the data within a texture object permanently until it is explicitly destroyed. The data will not lost even in low memory situation, except the process own this texture object is killed totally. In FFOS, during drag and drop, each of icon is destroyed and recreated again and again, it is waste of time and very inefficient. The re-uploading also introduce risk of fail to allocating memory in the middle of dragging. I am not sure whether the workaround of re-uploading is actually the real thing that need to do in this situation or not.

Comment 28

[Peter Chang[:pchang]]

(In reply to James Zhang from comment #27)
> Andrew's comment in spreadtrum bugzilla.
> 
> http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=298315
> 
> I believe there is something wrong inside FFOS.
> 
> There are many icons show on the desktop in this case. Each icon is
> represented by a texture object. After long press the icon, the icon will
> become shaking. During the drag and drop process, I found the texture object
> corresponding to each icon will be destroyed at first. And then be recreated
> again and the icon image is uploaded again. If the re-uploading failed or is
> forgotten, the texture object will be an empty texture and a black block
> will show on the desktop.
> 
Could you provide the GL draw call sequence about texture deletion?

In FFOS, each icon will only upload texture at the beginning of animation and you will see the TexImage2D[1] and TexSubImage2D GL draw cmds for texture uploading. We didn't free the texture first and then upload.

[1]http://dxr.mozilla.org/mozilla-central/source/gfx/gl/TextureImageEGL.cpp#246

> In general, OpenGL ES will keep the data within a texture object permanently
> until it is explicitly destroyed. The data will not lost even in low memory
> situation, except the process own this texture object is killed totally. In
> FFOS, during drag and drop, each of icon is destroyed and recreated again
> and again, it is waste of time and very inefficient. The re-uploading also
> introduce risk of fail to allocating memory in the middle of dragging. I am
> not sure whether the workaround of re-uploading is actually the real thing
> that need to do in this situation or not.

Comment 29

[Chiajung Hung [:chiajung]]

(In reply to James Zhang from comment #27)
> Andrew's comment in spreadtrum bugzilla.
> 
> http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=298315
> 
> I believe there is something wrong inside FFOS.
> 
> There are many icons show on the desktop in this case. Each icon is
> represented by a texture object. After long press the icon, the icon will
> become shaking. During the drag and drop process, I found the texture object
> corresponding to each icon will be destroyed at first. And then be recreated
> again and the icon image is uploaded again. If the re-uploading failed or is
> forgotten, the texture object will be an empty texture and a black block
> will show on the desktop.

No, we do not re-upload it. It is the first time upload while animation starts in this case.
And that is a driver bug that upload fail but GL_NO_ERROR returned while glGetError();

While homescreen is still, the whole homescreen page is rendered by CPU and uploaded as whole by graphicBuffer.

> 
> In general, OpenGL ES will keep the data within a texture object permanently
> until it is explicitly destroyed. The data will not lost even in low memory
> situation, except the process own this texture object is killed totally. In
> FFOS, during drag and drop, each of icon is destroyed and recreated again
> and again, it is waste of time and very inefficient. The re-uploading also
> introduce risk of fail to allocating memory in the middle of dragging. I am
> not sure whether the workaround of re-uploading is actually the real thing
> that need to do in this situation or not.

Peter provided the patch to prove it, did you try it? I think he narrowed down the problem to a single function call: glTexImage2D. And he also eliminated glSubTexImage2D call in this case.

Comment 30

[James Zhang (Spreadtrum)]

Attachment: ff2_gl.txt.tar.gz

Andrew's comment.

吴志华 (Andrew Wu) 2014-05-04 19:57:13 CST
Created attachment 28695 [details] [diff] [review]
opengl es call log

The attached file is the log before the long press till the icon is shaking.
The texture with name 5 is the texture used to draw the black block. Only texture related API call is recorded. You can search the glBindTexture(GL_TEXTURE_2D, 5) from the bottom. Then you will find the last texture uploading to texture 5 is to fill it with a blank texture of width 64 and height 93.
[reply] [−]  Private Comment 23 吴志华 (Andrew Wu) 2014-05-04 16:10:59 CST
Apparently home screen are not rendered as a big picture. The icons on the screen are rendered separately. And I do not mean the icon is re-uploaded in the animation. It is destroyed and re-uploaded between the animation.

Comment 31

[thomas tsai]

If the animation is disabled, will this issue happen?

Comment 32

[[e-mail], [e-mail]]

The black icon image is appeared while all the home screen icons are shacking. And it's not able to produce while we're dragging the icon. So I think if the shack animation is disabled, the issue cannot be reproduced.

Comment 33

[Peter Chang[:pchang]]

(In reply to James Zhang from comment #30)
> Created attachment 8417018 [details]
> ff2_gl.txt.tar.gz
> 
> Andrew's comment.
> 
> 吴志华 (Andrew Wu) 2014-05-04 19:57:13 CST
> Created attachment 28695 [details] [diff] [review]
> opengl es call log
> 
> The attached file is the log before the long press till the icon is shaking.
> The texture with name 5 is the texture used to draw the black block. Only
> texture related API call is recorded. You can search the
> glBindTexture(GL_TEXTURE_2D, 5) from the bottom. Then you will find the last
> texture uploading to texture 5 is to fill it with a blank texture of width
> 64 and height 93.
> [reply] [−]  Private Comment 23 吴志华 (Andrew Wu) 2014-05-04 16:10:59 CST
> Apparently home screen are not rendered as a big picture. The icons on the
> screen are rendered separately. And I do not mean the icon is re-uploaded in
> the animation. It is destroyed and re-uploaded between the animation.

For the animation icon, the width/height is 64x64. And I saw the right behavior from your log.
  35 D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
  36 D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
  39 D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42b17010);

This is the log for Texture 5 which the size is not match the animation icon. Do you always see this size when problem happened? How do you confirm it is related to black texture?

 238 D/libEGL  (   85): ------------------------------------------------------------------------------------glBindTexture(GL_TEXTURE_2D, 5);
 239 D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);

Comment 34

[Peter Chang[:pchang]]

(In reply to Ian Liu [:ianliu] from comment #32)
> The black icon image is appeared while all the home screen icons are
> shacking. And it's not able to produce while we're dragging the icon. So I
> think if the shack animation is disabled, the issue cannot be reproduced.

If you disable the animation, you may not see this issue but you can't make sure the black texture issue happen on other scenarios because we are using the quite basic(low-level) GL draw commands.

Comment 35

[Andrew Wu]

I enable the log from the beginning. And attach the gdb to b2g while the black block occurs. Found the black block is caused by texture 5. Then I pick all texture related call log from the full log. That's what you saw.

(In reply to peter chang[:pchang][:peter] from comment #33)
> (In reply to James Zhang from comment #30)
> > Created attachment 8417018 [details]
> > ff2_gl.txt.tar.gz
> > 
> > Andrew's comment.
> > 
> > 吴志华 (Andrew Wu) 2014-05-04 19:57:13 CST
> > Created attachment 28695 [details] [diff] [review]
> > opengl es call log
> > 
> > The attached file is the log before the long press till the icon is shaking.
> > The texture with name 5 is the texture used to draw the black block. Only
> > texture related API call is recorded. You can search the
> > glBindTexture(GL_TEXTURE_2D, 5) from the bottom. Then you will find the last
> > texture uploading to texture 5 is to fill it with a blank texture of width
> > 64 and height 93.
> > [reply] [−]  Private Comment 23 吴志华 (Andrew Wu) 2014-05-04 16:10:59 CST
> > Apparently home screen are not rendered as a big picture. The icons on the
> > screen are rendered separately. And I do not mean the icon is re-uploaded in
> > the animation. It is destroyed and re-uploaded between the animation.
> 
> For the animation icon, the width/height is 64x64. And I saw the right
> behavior from your log.
>   35 D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
>   36 D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64,
> 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
>   39 D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
> 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42b17010);
> 
> This is the log for Texture 5 which the size is not match the animation
> icon. Do you always see this size when problem happened? How do you confirm
> it is related to black texture?
> 
>  238 D/libEGL  (   85):
> -----------------------------------------------------------------------------
> -------glBindTexture(GL_TEXTURE_2D, 5);
>  239 D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64,
> 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);

Comment 36

[Peter Chang[:pchang]]

Attachment: TexImage2D/TexSubImage2D GL cmd dump

Comment 37

[Peter Chang[:pchang]]

(In reply to Andrew Wu from comment #35)
> I enable the log from the beginning. And attach the gdb to b2g while the
> black block occurs. Found the black block is caused by texture 5. Then I
> pick all texture related call log from the full log. That's what you saw.
> 
With attachment 8417765 [details] [diff] [review] and I only saw the 64x64 size when black icon happened.
And I only saw one TexImage2D for each animation icon.

James, could you apply attachment 8417765 [details] [diff] [review] and check the size of texture?
Because I didn't see the log Andrew mentioned.

peter@peter-desktop:~/b2g_debug_tarako$ adb shell logcat -vthreadtime|grep -E "TexImage"
01-01 08:16:12.670   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.680   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.690   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.710   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.720   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.720   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.730   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.740   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.740   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64
01-01 08:16:12.840   361   383 I Gecko   : [gl:0x47856000] > TexImage2D width 64 height 64

Comment 38

[Andrew Wu]

The problem is not the size, the problem is the texture is uploaded an empty texture and never get updated.

Comment 39

[Peter Chang[:pchang]]

(In reply to Andrew Wu from comment #38)
> The problem is not the size, the problem is the texture is uploaded an empty
> texture and never get updated.

Please let me know how to reproduce the issue you mentioned. Because I use attachment 8417765 [details] [diff] [review], but I couldn't reproduce the empty texture which never updates. Did you always see this symptom when black icon happen?

Comment 40

[Andrew Wu]

Yes, it always occurs. The version is around April 23.

(In reply to peter chang[:pchang][:peter] from comment #39)
> (In reply to Andrew Wu from comment #38)
> > The problem is not the size, the problem is the texture is uploaded an empty
> > texture and never get updated.
> 
> Please let me know how to reproduce the issue you mentioned. Because I use
> attachment 8417765 [details] [diff] [review], but I couldn't reproduce the
> empty texture which never updates. Did you always see this symptom when
> black icon happen?

Comment 41

[Bingqing Li]

I tried on build 20140506164003. It's not easy to reproduce now. 

Here are the steps:
-----------------------
1. Add 'LinkedIn' to homescreen.
2. Long press the icon of LinkedIn. Then, it will run into app icon managed mode.
3. Drag the icon to any page of home screen.
4. Repeat step 3 for several time, but I cannot tell how many times
   --> Sometimes one of the icons is changed to be black.
       (As far as I can tell, the icon of Camera is one of the most common icons that are changed to be black, and another is the icon of Tetris, which is added from everything.me as well.)

As a matter of fact, user can easily recover from this by tapping on home screen.


Build Info
-----------------------------------------------------
Gaia      746934a1e331b9ce578bd9fbdb4614d950baf765
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/771fedd3e904
BuildID   20140506164003
Version   28.1
ro.build.version.incremental=eng.cltbld.20140506.201925
ro.build.date=Tue May  6 20:19:33 EDT 2014

Comment 42

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: libEGL_blackbox.log

Peter, I can reproduce this and this log is after I set debug.egl.trace=1 in build.prop.

Comment 43

[Peter Chang[:pchang]]

(In reply to Kai-Zhen Li from comment #42)
> Created attachment 8420820 [details]
> libEGL_blackbox.log
> 
> Peter, I can reproduce this and this log is after I set debug.egl.trace=1 in
> build.prop.

I could see the strange 64,93 from Kai-Zhen log.

[Kai-Zhen's log]
peter@peter-desktop:~/rb2g_central_new$ grep -E "64, 64, 0|64, 93, 0|64, 64, GL_RGBA" /home/peter/libEGL_blackbox.log 
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x435ef010);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 93, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   84): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x428e6010);
D/libEGL  (   84): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43440010);

With debug.egl.trace enabled, I still saw black icon but no above TexImage2D calls with empty data.

[pchang's log]
peter@peter-desktop:~/rb2g_central_new$ grep -E "64, 64, 0|64, 93, 0|64, 64, GL_RGBA" ~/tarako.txt 
01-07 15:09:02.290   633   655 D libEGL  : glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
01-07 15:09:02.290   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42b77010);
01-07 15:09:02.290   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42b7c010);
01-07 15:09:02.290   633   655 D libEGL  : glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
01-07 15:09:02.530   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x430fc010);
01-07 15:09:02.530   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43a8e010);
01-07 15:09:02.580   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x430fc010);
01-07 15:09:02.580   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43a8e010);
01-07 15:09:02.620   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42b7c010);
01-07 15:09:02.760   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43a8e010);
01-07 15:09:02.760   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43c02010);
01-07 15:09:02.860   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x430fc010);
01-07 15:09:02.860   633   655 D libEGL  : glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43a8e010);

Comment 44

[Peter Chang[:pchang]]

Attachment: log with debug.egl.trace enabled

Comment 45

[Peter Chang[:pchang]]

Now I know where the texture with size 64,93 comes frome, because you try to reproduce the black icon on the first page of homescreen(everything.me).

The everything.me page is a little complex page because the icon is the combination of several canvas imgs. Please use the second page of homescreen to reproduce and you will see my log from comment 43.
And you can always see the glTexSubImage2D after glTexImage2D.

[STR]
a. adb shell setprop debug.egl.trace 1
b. adb shell stop b2g
c. adb shell start b2g
d. adb shell logcat|grep -E "glTexImage|glTexSubImage"
e. Go to the second page of homescreen and long press the icon.
f. repeat step e if issue doesn't happen

Comment 46

[Andrew Wu]

Attachment: ff.txt.tar.gz

This is the second page with black block. The texture 4 suppose to be the icon but shows as a black block. You will find it is not updated by a glTexSubImage. It is uploaded by glEGLImageTargetTexture2DOES.

Comment 47

[Peter Chang[:pchang]]

(In reply to Andrew Wu from comment #46)
> Created attachment 8423648 [details]
> ff.txt.tar.gz
> 
> This is the second page with black block. The texture 4 suppose to be the
> icon but shows as a black block. You will find it is not updated by a
> glTexSubImage. It is uploaded by glEGLImageTargetTexture2DOES.

I can't extract the attachment 8423648 [details]. Can you just paste the log directly? or re-upload the file.

Comment 48

[Andrew Wu]

Attachment: ff.txt.tar.gz

post again

Comment 49

[Kai-Zhen Li [:seinlin][:kli]]

Same error as the previous one.

$ tar xzvf ff.tgz 
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

Comment 50

[Andrew Wu]

Attachment: ff.txt

post the original log

Comment 51

[Andreas Gal :gal]

SharedSurface_Gralloc::Create is the only place we use that I believe. Are we maybe failing an allocation in fEGLImageTargetTexture2D? We are not checking for GL errors well in this function (OOM?). GenTextures is not checked either.

Comment 52

[Peter Chang[:pchang]]

From the raw log, I always see the glTexImage and glTexSubImage happened together. Where did you see the glTexSubImage lost? Can you paste the log directly?

For the animated image icons, it uses the share memory and uploads to GPU via glTexImage2D/glTexSubImage2D.

For the glEGLImageTargetTexture2DOES calls, most of contents in FxOS are painted within gralloc buffers(ex: the backgournd of homescreen) and call glEGLImageTargetTexture2DOES for uploading.
You will see lots of EGLImage calls not only during the animation mode.

About the texture 4, how do you know it is used for image icon? It's better to provide your analysis to save the discussion overhead.

peter@peter-desktop:~/rb2g_central_new$ grep -Ea1 "glTexImage|glTexSubImage|EGLImage" ~/ff.txt
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 18);
D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glActiveTexture(GL_TEXTURE0);
--
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 8);
D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42be2010);
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
--
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 20);
D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glActiveTexture(GL_TEXTURE0);
--
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 8);
D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x44200010);
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 4);

...
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 21);
D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glActiveTexture(GL_TEXTURE0);
--
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 8);
D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x44ee5010);
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
--
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 25);
D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glActiveTexture(GL_TEXTURE0);
--
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 8);
D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x4642b010);
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
--
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 27);
D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glActiveTexture(GL_TEXTURE0);
--
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 8);
D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x470d1010);
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
--
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 28);
D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glActiveTexture(GL_TEXTURE0);
--
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 8);
D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x47c00010);
D/libEGL  (   85): glPixelStorei(GL_UNPACK_ALIGNMENT, 4);

Comment 53

[Peter Chang[:pchang]]

(In reply to Andreas Gal :gal from comment #51)
> SharedSurface_Gralloc::Create is the only place we use that I believe. Are
> we maybe failing an allocation in fEGLImageTargetTexture2D? We are not
> checking for GL errors well in this function (OOM?). GenTextures is not
> checked either.

Inside the GrallocTextureHost.cpp in v1.3 or master, we will also use fEGLImageTargetTexture2D to bind the gralloc buffer.

The following is the example form master.
http://dxr.mozilla.org/mozilla-central/source/gfx/layers/opengl/GrallocTextureHost.cpp#445

Comment 54

[James Zhang (Spreadtrum)]

Attachment: ff2_gl.txt.tar.gz

Andrew said glTexImage2D's last param is null.

D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42b17010);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
D/libEGL  (   85): glDrawArrays(GL_TRIANGLES, 0, 6);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42cd1010);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
D/libEGL  (   85): glDrawArrays(GL_TRIANGLES, 0, 6);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 9);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x432f6010);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 9);
D/libEGL  (   85): glDrawArrays(GL_TRIANGLES, 0, 6);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43b29010);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 11);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43cc2010);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 12);
D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 12);
D/libEGL  (   85): ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x44dab010);

Comment 55

[James Zhang (Spreadtrum)]

Attachment: ff2_gl.txt

Comment 56

[Peter Chang[:pchang]]

(In reply to James Zhang from comment #54)
> Created attachment 8424546 [details]
> ff2_gl.txt.tar.gz
> 
> Andrew said glTexImage2D's last param is null.
> 
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64,
> 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
> 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42b17010);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 7);
> D/libEGL  (   85): glDrawArrays(GL_TRIANGLES, 0, 6);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64,
> 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
> 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42cd1010);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 8);
> D/libEGL  (   85): glDrawArrays(GL_TRIANGLES, 0, 6);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 9);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
> 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x432f6010);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 9);
> D/libEGL  (   85): glDrawArrays(GL_TRIANGLES, 0, 6);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64,
> 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
> 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43b29010);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 10);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 11);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
> 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43cc2010);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 12);
> D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 12);
> D/libEGL  (   85):
> ++++++++++++++++++++++++++++++++++++glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0,
> 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x44dab010);

Because we are using glTexSubImage2D to upload the real buffer data, glTexImage2D is used for buffer allocation only.

And there is always a glTexSubImage2D API after glTexImage2D.

Comment 57

[Kai-Zhen Li [:seinlin][:kli]]

Per offline discussion with Andrew and James, there could be two errors in the bug.

1. Everything.me page, it seems texture content is not uploaded to GPU correctly, should use the correct API to upload.

2. Second page, Andrew will continue investigate if there is any error during allocate and upload.

It cause by different

Peter, do you have any idea on item 1?

Comment 58

[Kai-Zhen Li [:seinlin][:kli]]

Additional to comment 57.
The blackbox in Everything.me page and Second page could be caused by different error.

Comment 59

[Peter Chang[:pchang]]

(In reply to Kai-Zhen Li from comment #57)
> Per offline discussion with Andrew and James, there could be two errors in
> the bug.
> 
> 1. Everything.me page, it seems texture content is not uploaded to GPU
> correctly, should use the correct API to upload.
> 
[Peter]I would prefer to wait the analysis of item 2 because we didn't have this problem on other device in everyting.me or second pages.
> 2. Second page, Andrew will continue investigate if there is any error
> during allocate and upload.
> 
> It cause by different
> 
> Peter, do you have any idea on item 1?

Comment 60

[Andrew Wu]

Attachment: ff_tex.txt

Here is the log of black block.
In line 423 and 429, texture 4 is uploaded a texture.
But in line 666, texture 4 is deleted.
Then the later rendering draw a black block on screen.

In this log, only texture 4 is deleted besides texture 1.

Comment 61

[Andrew Wu]

Attachment: ff.txt

The original log of last comment

Comment 62

[James Zhang (Spreadtrum)]

Can we workaround for this issue, re-upload texture patch?

Comment 63

[Peter Chang[:pchang]]

(In reply to Andrew Wu from comment #61)
> Created attachment 8430760 [details]
> ff.txt
> 
> The original log of last comment

From attachment 8430760 [details], I saw the texture 4 was deleted and soon another texture 30 was created.
But I couldn't reproduce similiar egl sequence you provided.
andrew, are you able to reproduce the same log every time?
If not, do you still see DeleteTexture call before BindTexture?

In my side, I always see several TexImage2D/TexSubImage2D calls happened together and no additional TexImage called later when black icon happend.
BTW, I see the the following from my tarako. It looks like you modify the libEGL.
andrew, could you attach your libEGL.so and patch?

  396 01-01 11:58:57.540   484   506 D libEGL  : glDeleteTextures(1, (const GLuint *) 0x43d70650);

[info from ff.txt]
4178:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 17);
4179:D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
4181:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 17);
4188:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 17);
4190:D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43e4e010);
4289:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 18);
4290:D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
4301:D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42f60010);
4324:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 18);

5529:D/libEGL  (   85): ------------------------------------------------------------------------------------glDeleteTextures(1, [4, ])
5530:D/libEGL  (   85): ------------------------------------------------------------------------------------glDeleteTextures(1, [4, ])
5531:D/libEGL  (   85): ------------------------------------------------------------------------------------glDeleteTextures(1, [4, ])
5672:D/libEGL  (   85): ------------------------------------------------------------------------------------glBindTexture(GL_TEXTURE_2D, 4);
5705:D/libEGL  (   85):     14, 73, 0, 1

6612:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);
6613:D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
6615:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);
6622:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);
6624:D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64, GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42bf5010);
6647:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);

7059:D/libEGL  (   85): ------------------------------------------------------------------------------------glBindTexture(GL_TEXTURE_2D, 4);
7092:D/libEGL  (   85):     14, 73, 0, 1
7107:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 5);
7130:D/libEGL  (   85):     95, 73, 0, 1
7145:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 6);
7193:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 18);
7226:D/libEGL  (   85):     169, 73, 0, 1

Comment 64

[Andrew Wu]

Yes, I modified log outpot of glDeleteTextures. It is very simple. glDeleteTextures only take 2 parameters, the last one is the address of an array of texture names, the first one is the length of the array. You can add code to print the content of array very easy.

And also yes, I have reproduced the sequence several times. You must add modified log of glDeleteTextures to make things more clear.

(In reply to peter chang[:pchang][:peter] from comment #63)
> (In reply to Andrew Wu from comment #61)
> > Created attachment 8430760 [details]
> > ff.txt
> > 
> > The original log of last comment
> 
> From attachment 8430760 [details], I saw the texture 4 was deleted and soon
> another texture 30 was created.
> But I couldn't reproduce similiar egl sequence you provided.
> andrew, are you able to reproduce the same log every time?
> If not, do you still see DeleteTexture call before BindTexture?
> 
> In my side, I always see several TexImage2D/TexSubImage2D calls happened
> together and no additional TexImage called later when black icon happend.
> BTW, I see the the following from my tarako. It looks like you modify the
> libEGL.
> andrew, could you attach your libEGL.so and patch?
> 
>   396 01-01 11:58:57.540   484   506 D libEGL  : glDeleteTextures(1, (const
> GLuint *) 0x43d70650);
> 
> [info from ff.txt]
> 4178:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 17);
> 4179:D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0,
> GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
> 4181:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 17);
> 4188:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 17);
> 4190:D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64,
> GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x43e4e010);
> 4289:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 18);
> 4290:D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0,
> GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
> 4301:D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64,
> GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42f60010);
> 4324:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 18);
> 
> 5529:D/libEGL  (   85):
> -----------------------------------------------------------------------------
> -------glDeleteTextures(1, [4, ])
> 5530:D/libEGL  (   85):
> -----------------------------------------------------------------------------
> -------glDeleteTextures(1, [4, ])
> 5531:D/libEGL  (   85):
> -----------------------------------------------------------------------------
> -------glDeleteTextures(1, [4, ])
> 5672:D/libEGL  (   85):
> -----------------------------------------------------------------------------
> -------glBindTexture(GL_TEXTURE_2D, 4);
> 5705:D/libEGL  (   85):     14, 73, 0, 1
> 
> 6612:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);
> 6613:D/libEGL  (   85): glTexImage2D(GL_TEXTURE_2D, 0, 6408, 64, 64, 0,
> GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x00000000);
> 6615:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);
> 6622:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);
> 6624:D/libEGL  (   85): glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 64, 64,
> GL_RGBA, GL_UNSIGNED_BYTE, (const GLvoid *) 0x42bf5010);
> 6647:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 30);
> 
> 7059:D/libEGL  (   85):
> -----------------------------------------------------------------------------
> -------glBindTexture(GL_TEXTURE_2D, 4);
> 7092:D/libEGL  (   85):     14, 73, 0, 1
> 7107:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 5);
> 7130:D/libEGL  (   85):     95, 73, 0, 1
> 7145:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 6);
> 7193:D/libEGL  (   85): glBindTexture(GL_TEXTURE_2D, 18);
> 7226:D/libEGL  (   85):     169, 73, 0, 1

Comment 65

[Andrew Wu]

Attachment: ff_home2.txt

Single icon on third desktop. Pattern 1, texture 1 is the black block, upload by glTexImage2D and glTexSubImage2D, then deleted by glDeleteTextures

Comment 66

[Andrew Wu]

Attachment: ff_home4.txt

Single icon on third desktop. Pattern 2, texture 1 is the black block, upload by glEGLImageTargetTexture2DOES, then deleted by glDeleteTextures

Comment 67

[Andrew Wu]

Attachment: ff_home3.txt

Single icon on third desktop. Pattern 3, texture 1 is the black block, upload by glEGLImageTargetTexture2DOES, no glDeleteTextures. But black block still appears. Investigating.

Comment 68

[Montoya Clemmons (MClemmons)]

During verification of bug 978739, exploratory testing with a bookmarked icon from Browser activity yielded similar behavior of black block replacing both e.me icons as well as bookmarked icons - intermittently in each instance on latest 1.3T build. You may needinfo if you desire video/STR/etc of this latest experience.

Comment 69

[Sotaro Ikeda [:sotaro]]

It seems difficult to fix GL upload problem. So, I tried other thing. For sync ImageLayer, shmem was used for it until b2g v1.3. It is changed as to use gralloc buffer since b2g v1.4 by Bug 946720. So, if we use gralloc for sync ImageLayer, the problem could be bypassed.

Comment 70

[Sotaro Ikeda [:sotaro]]

Attachment: patch - use gralloc for sync ImageLayer

Comment 71

[Sotaro Ikeda [:sotaro]]

Since applying attachment 8431770 [details] [diff] [review] in my local environment, I did not see the black rectangle that I saw before applying the patch.

Comment 72

[Sotaro Ikeda [:sotaro]]

Can someone test if attachment 8431770 [details] [diff] [review] fix the problem?

Comment 73

[James Zhang (Spreadtrum)]

Sotaro, I will try this patch. Thank you.

Comment 74

[James Zhang (Spreadtrum)]

Andrew, see http://people.mozilla.org/~pchang/tarako.mp4

Comment 75

[James Zhang (Spreadtrum)]

(In reply to Sotaro Ikeda [:sotaro] from comment #72)
> Can someone test if attachment 8431770 [details] [diff] [review] fix the
> problem?

Sotaro, your patch is ok. Can you review and land this patch on v1.3t. Thanks.

Comment 76

[James Zhang (Spreadtrum)]

Sotaro, your patch is OK for this bug, but it can't fix Bug 1012551.
Can you help to take a look?

Comment 77

[Sotaro Ikeda [:sotaro]]

Stealing this bug.

Comment 78

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8431770 [details] [diff] [review]
patch - use gralloc for sync ImageLayer

nical, can you review the patch? This patch is for b2g-v1.3T. It is created based on attachment 8375279 [details] [diff] [review] in Bug 946720.

Comment 79

[Sotaro Ikeda [:sotaro]]

(In reply to James Zhang from comment #76)
> Sotaro, your patch is OK for this bug, but it can't fix Bug 1012551.
> Can you help to take a look?

I suspect this bug is caused by gpu driver's bug. It bypass texture data upload by using gralloc for sync image layer. It does not change how WebGL is rendered. It uses different path. WebGL uses SurfaceStream. It also uses GPU differently compared to Android. I suspect that it also hit gpu driver's bug.

Comment 80

[James Zhang (Spreadtrum)]

Sotaro, your patch may cause minidump.
We meet a lot of same minidump after land your WIP patch.

---- stack ----
0  libxul.so!mozalloc_abort(char const*) [mozalloc_abort.cpp : 30 + 0x4]
1  libxul.so!NS_DebugBreak [nsDebugImpl.cpp : 434 + 0x5]
2  libxul.so!mozilla::layers::PGrallocBufferParent::Write(mozilla::layers::PGrallocBufferParent*, IPC::Message*, bool) [PGrallocBufferParent.cpp : 348 + 0x17]
3  libxul.so!mozilla::layers::PGrallocBufferParent::Send__delete__(mozilla::layers::PGrallocBufferParent*) [PGrallocBufferParent.cpp : 58 + 0x5]
4  libxul.so!mozilla::layers::GrallocTextureHostOGL::DeallocateSharedData() [GrallocTextureHost.cpp : 277 + 0x3]
5  libxul.so!mozilla::layers::CompositableHost::~CompositableHost [CompositableHost.cpp : 43 + 0x5]
6  libxul.so!mozilla::layers::ImageHost::~ImageHost [ImageHost.cpp : 36 + 0x5]
7  libxul.so!mozilla::layers::ImageHost::~ImageHost [ImageHost.cpp : 36 + 0x5]
8  libxul.so!mozilla::RefPtr<mozilla::gfx::DataSourceSurface>::~RefPtr + 0x15
9  libxul.so!mozilla::layers::CompositableParent::~CompositableParent [CompositableHost.cpp : 305 + 0x7]
10  libxul.so!mozilla::layers::CompositableParent::~CompositableParent [CompositableHost.cpp : 305 + 0x3]
11  libxul.so!mozilla::dom::ContentChild::DeallocPBlobChild(mozilla::dom::PBlobChild*) + 0xb
12  libxul.so!mozilla::layers::PLayerTransactionParent::DeallocSubtree() [PLayerTransactionParent.cpp : 809 + 0x7]
13  libxul.so!mozilla::layers::PCompositorParent::DeallocSubtree() [PCompositorParent.cpp : 935 + 0x5]
14  libxul.so!mozilla::layers::PCompositorParent::OnChannelError() [PCompositorParent.cpp : 810 + 0x5]
15  libxul.so!mozilla::ipc::MessageChannel::NotifyMaybeChannelError() [MessageChannel.cpp : 1532 + 0x5]
16  libxul.so!mozilla::ipc::MessageChannel::OnNotifyMaybeChannelError() [MessageChannel.cpp : 1561 + 0x5]
17  libxul.so!RunnableMethod<WebCore::ReverbConvolver, void (WebCore::ReverbConvolver::*)(), Tuple0>::Run() [tuple.h : 383 + 0x5]
18  libxul.so!MessageLoop::RunTask(Task*) [message_loop.cc : 340 + 0x5]
19  libxul.so!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) [message_loop.cc : 348 + 0x5]
20  libxul.so!MessageLoop::DoWork() [message_loop.cc : 448 + 0x7]
21  libxul.so!base::MessagePumpDefault::Run(base::MessagePump::Delegate*) [message_pump_default.cc : 34 + 0x7]
22  libxul.so!MessageLoop::RunInternal() [message_loop.cc : 222 + 0x5]
23  libxul.so!MessageLoop::Run() [message_loop.cc : 215 + 0x5]
24  libxul.so!base::Thread::ThreadMain() [thread.cc : 162 + 0x5]
25  libxul.so!ThreadFunc [platform_thread_posix.cc : 39 + 0x5]
26  libc.so!__thread_entry [pthread.c : 217 + 0x6]
27  libc.so!pthread_create [pthread.c : 357 + 0xe]
>>>> mozilla/Crash Reports/pending/30dd3274-74c3-2500-56d29aa4-3891ad56.dmp <<<<

Comment 81

[Sotaro Ikeda [:sotaro]]

Hi James, the the above crash log just says that error happened on ipc channel. It say almost nothing about actual cause of the crash. Can you provide the full crash log with logcat?

Comment 82

[Sotaro Ikeda [:sotaro]]

Is there a concrete STR to cause the crash?

Comment 83

[Sotaro Ikeda [:sotaro]]

It might be possible that v1.3T's TextureHost and GrallocBufferActor are not robust enough to ipc Channel error.

Comment 84

[Sotaro Ikeda [:sotaro]]

V1.3T seems not have Bug 966446 fix. This seems necessary to prevent the crash in Comment 80. From the crash log, the crash seem to be caused by double delete.

Comment 85

[Sotaro Ikeda [:sotaro]]

James, can you apply Bug 966446 fix? It might fix the crash in Comment 80.

Comment 86

[James Zhang (Spreadtrum)]

OK, we will run monkey test to verify.

Comment 87

[ying.xu]

(In reply to Sotaro Ikeda [:sotaro] from comment #82)
> Is there a concrete STR to cause the crash?

We meet this problem during monkey test

Comment 88

[James Zhang (Spreadtrum)]

(In reply to Sotaro Ikeda [:sotaro] from comment #85)
> James, can you apply Bug 966446 fix? It might fix the crash in Comment 80.

v1.3 patch conflict

Comment 89

[Keven Kuo [:kkuo]]

Set NI to Sotaro.

--
Keven

(In reply to James Zhang from comment #88)
> (In reply to Sotaro Ikeda [:sotaro] from comment #85)
> > James, can you apply Bug 966446 fix? It might fix the crash in Comment 80.
> 
> v1.3 patch conflict

Comment 90

[James Zhang (Spreadtrum)]

We will land bug 966446 and this bug patch today and run monkey test to verify.

Comment 91

[James Zhang (Spreadtrum)]

Sotaro, can you land this bug patch?
Today monkey test is OK with this bug patch.

Comment 92

[Nicolas Silva [:nical]]

Comment on attachment 8431770 [details] [diff] [review]
patch - use gralloc for sync ImageLayer

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

::: gfx/layers/client/CompositableClient.cpp
@@ +226,5 @@
> +DisableGralloc(SurfaceFormat aFormat)
> +{
> +  if (aFormat == gfx::FORMAT_A8) {
> +    return true;
> +  }

Shouldn't you check that the texture is at least 64x64 on some android versions?

::: gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp
@@ -398,5 @@
> -  // small anyway, so fall back on shared memory plus a texture
> -  // upload.
> -  if (aSize.width < 64) {
> -    return false;
> -  }

What makes it OK to remove this check?

Comment 93

[Sotaro Ikeda [:sotaro]]

(In reply to Nicolas Silva [:nical] from comment #92)
> Comment on attachment 8431770 [details] [diff] [review]
> patch - use gralloc for sync ImageLayer
> 
> Review of attachment 8431770 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/layers/client/CompositableClient.cpp
> @@ +226,5 @@
> > +DisableGralloc(SurfaceFormat aFormat)
> > +{
> > +  if (aFormat == gfx::FORMAT_A8) {
> > +    return true;
> > +  }
> 
> Shouldn't you check that the texture is at least 64x64 on some android
> versions?
> 
> ::: gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp
> @@ -398,5 @@
> > -  // small anyway, so fall back on shared memory plus a texture
> > -  // upload.
> > -  if (aSize.width < 64) {
> > -    return false;
> > -  }
> 
> What makes it OK to remove this check?

This is a workaround for adreno200. Spreadtrum's device seems not have such defect. But current tarako device seems to have another defect aorund uploading opengl texture data. Therefore, the patch is changed as to use gralloc texture as much as possible even in ICS platform. This 64 size limit is already removed since JB.

Comment 94

[James Zhang (Spreadtrum)]

Hi Sotaro,

    Do you have any keywords to search workaround for qcom chipset workaround? I think we should find and remove them on v1.3t branch.

Comment 95

[Sotaro Ikeda [:sotaro]]

IIRC, adreno 200's workarounds that affect all gonk platforms are only following 2 places.

[1]
http://mxr.mozilla.org/mozilla-b2g28_v1_3t/source/gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp#413
[2]
http://mxr.mozilla.org/mozilla-b2g28_v1_3t/source/gfx/layers/RotatedBuffer.cpp#379

[1] disable gralloc buffer when width is less than 64.
[2] extends thebes layer buffer when height is less than 32.

"Adreno" seems better keyword to check, like the following. Though, [1] does not have Adreno keyword.
http://dxr.mozilla.org/mozilla-central/search?q=Adreno&case=true

In current master, [1] is moved to the following is the check is enabled only on ICS.
http://mxr.mozilla.org/mozilla-central/source/gfx/layers/client/TextureClient.cpp#215

Comment 96

[James Zhang (Spreadtrum)]

git log | grep -i adreno

And I found 16 commit.

1.
commit 165c49b722d1ec321959b2b048072b68ce33e3f2
Author: Jeff Muizelaar <[e-mail]>
Date:   Wed May 28 13:57:13 2014 -0400

    Bug 1014209 - Only call DrawBuffers if necessary. r=jgilbert, a=1.4+

    DrawBuffers seems to cause a flush on the adreno 300 so we only want to do it if we need to.

2.
commit 746bca65a713704e8e4455af7b8a2e838d98c145
Author: Benoit Jacob <[e-mail]>
Date:   Sat Jun 2 16:28:18 2012 -0400

    Bug 760675 - update adreno blacklisting to not use the global context - r=jrmuizel

    The current Adreno blacklists hard-asserts (even in release builds) that there is a global context, as it needs it to get renderer info. That was done as, at the time (bug 736123) there were GL context creation crashes there.

    However, without share groups, I can't reproduce the context creation crashes anymore, so this approach doesn't seem to be needed anymore. If we were unlucky and there still were context creation crashes, the solution would be the java thread thing mentioned in comment 0, anyway.

3.
commit 7ddda953bfd6fec1293155389889222f6b4fcda6
Author: Benoit Jacob <[e-mail]>
Date:   Tue May 8 15:55:52 2012 -0400

    Bug 736123 - short-term fix: blacklist adreno using the global GLContext to get renderer info - r=bgirard

    It really works, but it's not future-proof as it relies on the global GL context that's going away soon. But it probably won't go away in Aurora 14, so this should at least allow us to ship Fennec 14.

    Longer term, we need to do some message passing so we can get the LayerManager's OpenGL context's renderer id, from the OMTC thread.

4.
commit 2d48ade1d9d9699c886b2ec1153caa4322da86bb
Author: Benoit Girard <[e-mail]>
Date:   Tue Feb 14 13:19:46 2012 -0500

    Change tilesize to 256x256 for progressive upload and adreno POT uploads

5.
commit 4a27a14d08cb725994a901c8c5c2afa01933fbe9
Author: Benoit Girard <[e-mail]>
Date:   Tue Feb 14 13:16:18 2012 -0500

    Remove adreno fix, it only makes the crash less likely

6.
commit 8a70df11c7e8c4ec6afa74bbb107e31039cee5b8
Author: Jeff Gilbert <[e-mail]>
Date:   Tue Jun 4 15:23:40 2013 -0700

    Bug 875696 - Disable oes_standard_derivatives for Adreno 320 for being broken. - r=bjacob

7.
commit 6116886dbcf9df04003825ab4d83840b3581771a
Author: Chris Lord <[e-mail]>
Date:   Wed May 15 16:45:08 2013 +0100

    Bug 869696 - Use an alternative method to unlock gralloc textures on Adreno (TM) 205. r=bjacob

    Targeting the NULL EGLImage causes slowness on the Geeksphone Peak,
    and assumedly, other "Adreno (TM) 205" devices. Achieve the same
    effect by deleting the GL texture instead.

8.
commit 120069ee3f87e9eb042003f28d93274f7ec5cb9e
Author: Chris Lord <[e-mail]>
Date:   Wed May 15 16:43:22 2013 +0100

    Bug 869696 - Add AdrenoTM205 to renderer enum. r=bjacob

    Add the 'Adreno (TM) 205' renderer string to the renderer enum in GLContext.

9.
commit dc9a4a513c8c9121ac51f32b69213bed798154e3
Author: James Willcox <[e-mail]>
Date:   Sat Feb 23 12:14:11 2013 -0500

    Bug 844468 - Work around missing GL_OES_EGL_sync in Adreno r=vlad

10.
commit 403c028f49176a1d10ed6a30f6c37ef4d01eecfb
Author: Vladimir Vukicevic <[e-mail]>
Date:   Fri Aug 3 13:40:41 2012 -0400

    b=780213; don't call glDeleteTextures when len == 0 in TextureReaper, because Adreno; r=snorp

11.
commit 725493a9dffdcee6db3f3f9511bebd3a625dcd4e
Author: Benoit Jacob <[e-mail]>
Date:   Thu Jul 5 10:13:04 2012 -0400

    Bug 766251 - 5/5 - update Adreno WebGL blacklisting - r=jrmuizel


12.
commit 746bca65a713704e8e4455af7b8a2e838d98c145
Author: Benoit Jacob <[e-mail]>
Date:   Sat Jun 2 16:28:18 2012 -0400

    Bug 760675 - update adreno blacklisting to not use the global context - r=jrmuizel

    The current Adreno blacklists hard-asserts (even in release builds) that there is a global context, as it needs it to get renderer info. That was done as, at the time (bug 736123) there were GL context creation crashes there.

    However, without share groups, I can't reproduce the context creation crashes anymore, so this approach doesn't seem to be needed anymore. If we were unlucky and there still were context creation crashes, the solution would be the java thread thing mentioned in comment 0, anyway.

13.
commit b1836ff315f28d50ae2b57944863f43d722f10f5
Author: Benoit Jacob <[e-mail]>
Date:   Sat Jun 2 16:28:16 2012 -0400

    Bug 760675 - don't create a global context at all, on Android - r=jrmuizel

    Indeed, it's currently unused except for Adreno blacklisting (see next commit) as
    we don't do texture sharing just yet. We will soon do, though (bug 728524) and then
    it is possible that on certain drivers we will have to use the global context as a
    mean to share textures (if EGLImage can't be used). We'll see.

14.
commit c25e00d46c111c1afa3622d5e4e3ef70f14e2de8
Author: Benoit Jacob <[e-mail]>
Date:   Mon Apr 30 17:43:12 2012 -0400

    Bug 736123 - blacklist Adreno renderers for WebGL - r=joe


15.
commit fa376f2332b73a10ad58870962741433c116e893
Author: George Wright <[e-mail]>
Date:   Sat Feb 18 21:23:06 2012 -0500

    Bug 721489 - Older Adreno 200 drivers intermittently crash when uploading RGB565 textures with glTexImage2D - r=jrmuizel

16.
commit 6bcb6bfee61043c28cc98428e8ed7b130c7e4630
Author: Benoit Girard <[e-mail]>
Date:   Thu Feb 9 17:52:03 2012 -0500

    Bug 721489 - Allocate a PoT Shmem for the Adreno. This replaces segfaults by visual artifacts

    --HG--
    extra : rebase_source : 400e392843cf2d15b941e7e94b736106e6b447e2

17.
commit 4ea08cd7d09ab001ac8505e7df4f89cea23fcc91
Author: George Wright <[e-mail]>
Date:   Tue Jan 24 19:44:48 2012 -0500

    Bug 721467 - Add an optional codepath (currently enabled only for Adreno 200 GPUs) to only use glTexImage2D for texture uploads as glTexSubImage2D can be slow and/or buggy r=joe,BenWa

    --HG--
    extra : rebase_source : 0f2903fe23edf3b191ae5dcfa7df6d9066d1d952

Comment 97

[Sotaro Ikeda [:sotaro]]

Nical, Comment 93 is enough answer to your question?

Comment 98

[Nicolas Silva [:nical]]

Comment on attachment 8431770 [details] [diff] [review]
patch - use gralloc for sync ImageLayer

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

If this will land in a branch that will only be used with devices that don't need the 64x64 gralloc buffer workarounds, then everything is good (which seems to be the case according to the comments)

Comment 99

[Sotaro Ikeda [:sotaro]]

fabrice seems away until june/17.

Comment 100

[James Zhang (Spreadtrum)]

(In reply to Sotaro Ikeda [:sotaro] from comment #99)
> fabrice seems away until june/17.

Anybody has v1.3t merge permission?

Comment 101

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to James Zhang from comment #100)
> (In reply to Sotaro Ikeda [:sotaro] from comment #99)
> > fabrice seems away until june/17.
> 
> Anybody has v1.3t merge permission?

James, there is keywords "checkin-needed", so I think the patch will get landed very soon.

Comment 102

[Peter Chang[:pchang]]

Comment on attachment 8431770 [details] [diff] [review]
patch - use gralloc for sync ImageLayer

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

::: gfx/layers/client/ClientImageLayer.cpp
@@ +114,2 @@
>      mImageClientTypeContainer = autoLock.GetImage() ?
> +                                  CompositableType::BUFFER_IMAGE_BUFFERED : CompositableType::BUFFER_UNKNOWN;

This is the major changes to switch image icon from share memory to gralloc buffer. And this could avoid TexImage2D/TexSubImage2D calls.

::: gfx/layers/ipc/ShadowLayerUtilsGralloc.cpp
@@ -398,5 @@
> -  // small anyway, so fall back on shared memory plus a texture
> -  // upload.
> -  if (aSize.width < 64) {
> -    return false;
> -  }

If we only consider the image icons from homescreen, it usually creates icon with 64x64 size. Therefore, this bug will not hit this workaround.

Comment 103

[Peter Chang[:pchang]]

(In reply to James Zhang from comment #94)
> Hi Sotaro,
> 
>     Do you have any keywords to search workaround for qcom chipset
> workaround? I think we should find and remove them on v1.3t branch.

James, please check comment 102 about the concern of size 64 workaround.

Comment 104

[u459114]

Peter is right. This change is the main reason that black icon disappear
> +mImageClientTypeContainer = autoLock.GetImage() ?
> +                                  CompositableType::BUFFER_IMAGE_BUFFERED : 
> +                                  CompositableType::BUFFER_UNKNOWN;

The side effect of this change is memory footprint increasing since we use double buffer to workaround tex-upload issue.

Comment 105

[ying.xu]

(In reply to peter chang[:pchang][:peter] from comment #102)
> Comment on attachment 8431770 [details] [diff] [review]
> patch - use gralloc for sync ImageLayer
> 
> Review of attachment 8431770 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/layers/client/ClientImageLayer.cpp
> @@ +114,2 @@
> >      mImageClientTypeContainer = autoLock.GetImage() ?
> > +                                  CompositableType::BUFFER_IMAGE_BUFFERED : CompositableType::BUFFER_UNKNOWN;
> 


> This is the major changes to switch image icon from share memory to gralloc
> buffer. And this could avoid TexImage2D/TexSubImage2D calls.

Hi, peter.
I don't understand this.
Can you give us more details about this?

Comment 106

[Peter Chang[:pchang]]

(In reply to ying.xu from comment #105)
> (In reply to peter chang[:pchang][:peter] from comment #102)
> > Comment on attachment 8431770 [details] [diff] [review]
> > patch - use gralloc for sync ImageLayer
> > 
> > Review of attachment 8431770 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > ::: gfx/layers/client/ClientImageLayer.cpp
> > @@ +114,2 @@
> > >      mImageClientTypeContainer = autoLock.GetImage() ?
> > > +                                  CompositableType::BUFFER_IMAGE_BUFFERED : CompositableType::BUFFER_UNKNOWN;
> > 
> 
> 
> > This is the major changes to switch image icon from share memory to gralloc
> > buffer. And this could avoid TexImage2D/TexSubImage2D calls.
> 
> Hi, peter.
> I don't understand this.
> Can you give us more details about this?

Hi Ying,

Before this patch, gecko uses share memory to save image content. And gecko calls TexImage2D/TexSubImage2D to upload texture to GPU.

With this patch, gecko uses the graphic buffer to save image content and it calls EGLImageTargetTexture2D to upload texture instead of TexImgae2D API.

Comment 107

[u459114]

(In reply to peter chang[:pchang][:peter] from comment #106)
> (In reply to ying.xu from comment #105)
> > (In reply to peter chang[:pchang][:peter] from comment #102)
> > Hi, peter.
> > I don't understand this.
> > Can you give us more details about this?
> 
> Hi Ying,
> 
> Before this patch, gecko uses share memory to save image content. And gecko
> calls TexImage2D/TexSubImage2D to upload texture to GPU.
> 
> With this patch, gecko uses the graphic buffer to save image content and it
> calls EGLImageTargetTexture2D to upload texture instead of TexImgae2D API.

I think that change can be removed. Please see my comment in bug 1012551
https://bugzilla.mozilla.org/show_bug.cgi?id=1012551#c28
But we should double confirm with sotaro

Comment 108

[Sotaro Ikeda [:sotaro]]

(In reply to C.J. Ku[:cjku] from comment #107)
> (In reply to peter chang[:pchang][:peter] from comment #106)
> > (In reply to ying.xu from comment #105)
> > > (In reply to peter chang[:pchang][:peter] from comment #102)
> > > Hi, peter.
> > > I don't understand this.
> > > Can you give us more details about this?
> > 
> > Hi Ying,
> > 
> > Before this patch, gecko uses share memory to save image content. And gecko
> > calls TexImage2D/TexSubImage2D to upload texture to GPU.
> > 
> > With this patch, gecko uses the graphic buffer to save image content and it
> > calls EGLImageTargetTexture2D to upload texture instead of TexImgae2D API.
> 
> I think that change can be removed. Please see my comment in bug 1012551
> https://bugzilla.mozilla.org/show_bug.cgi?id=1012551#c28
> But we should double confirm with sotaro

Thank for the notification. I am going to check it.

Comment 109

[Sotaro Ikeda [:sotaro]]

This bug exist on v1.3 and v1.3T. It might be better to land also to v1.3.

Comment 110

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #109)
> This bug exist on v1.3 and v1.3T. It might be better to land also to v1.3.

I am not sure how to nominate also to v.1.3 in bugzilla.

Comment 111

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8431770 [details] [diff] [review]
patch - use gralloc for sync ImageLayer

obsolete it. Actual cause of the bug is found on bug 1012551.

Comment 112

[Sotaro Ikeda [:sotaro]]

After applying bug 1012551 fix. This bug's problem seems also fixed.

Comment 113

[Sotaro Ikeda [:sotaro]]

:cjku, if your sides confirmation is also same to Comment 112, please close this bug as dup of bug 1012551.

Comment 114

[Sotaro Ikeda [:sotaro]]

Bug 1012551 Comment 32 is enough to close this bug as dup of bug 1012551.