Closed Bug 994590 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1012551

People

(Reporter: iliu, Unassigned)

References

Details

(Whiteboard: [partner-blocker][sprd298315][only-b2g-v1.3T])

Attachments

(16 files, 5 obsolete files)

20140406_170204.jpg
1.13 MB, image/jpeg
Details
dmesg_black_icon.txt
130.55 KB, text/plain
Details
IMG_1101.MOV
1.57 MB, video/quicktime
Details
2014-04-10-10-28-40.png
185.10 KB, image/png
Details
easy way to reproduce black icon
177.84 KB, image/png
Details
debug patch - re-upload texture when black icon happens
3.25 KB, patch
Details | Diff | Splinter Review
TexImage2D/TexSubImage2D GL cmd dump
1.04 KB, patch
Details | Diff | Splinter Review
libEGL_blackbox.log
2.52 MB, text/x-log
Details
log with debug.egl.trace enabled
560.64 KB, text/plain
Details
ff.txt
1.88 MB, text/plain
Details
ff2_gl.txt
112.79 KB, text/plain
Details
ff_tex.txt
229.14 KB, text/plain
Details
ff.txt
2.00 MB, text/plain
Details
ff_home2.txt
242.33 KB, text/plain
Details
ff_home4.txt
329.09 KB, text/plain
Details
ff_home3.txt
265.71 KB, text/plain
Details
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
blocking-b2g: --- → 1.3T?
Flags: needinfo?(pchang)
Attached image 20140406_170204.jpg —
screen shot
Attached video IMG_1101.MOV —
Please reference the record. It's easy to understand the reproduced steps.
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"}]
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.
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?
(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.
Attached image 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
triage: 1.3T+ for broken display on icon
blocking-b2g: 1.3T? → 1.3T+
Component: Gaia → Gaia::Homescreen
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
Keywords: qawanted
(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.
Keywords: qawanted
(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.
Flags: needinfo?(pchang)
Assignee: nobody → pchang
I didn't see any gl error after texture uploading.
(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
(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.
(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.
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.
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
Flags: needinfo?(james.zhang)
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
Flags: needinfo?(james.zhang)
(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.
Flags: needinfo?(james.zhang)
(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.
(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.
Flags: needinfo?(james.zhang) → needinfo?(ying.xu)
Blocks: 990494
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.
Blocks: 989847
Whiteboard: [POVB] [partner-blocker]
No longer blocks: 989847
Depends on: 989847
No longer depends on: 989847
Whiteboard: [POVB] [partner-blocker] → [POVB] [partner-blocker][sprd303701][need sprd gpu help]
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.
(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.
Status: NEW → ASSIGNED
Component: Gaia::Homescreen → Graphics
Product: Firefox OS → Core
Jason will ask gpu team to support.
Assignee: pchang → jason.liu
Whiteboard: [POVB] [partner-blocker][sprd303701][need sprd gpu help] → [POVB] [partner-blocker][sprd298315][need sprd gpu help]
Whiteboard: [POVB] [partner-blocker][sprd298315][need sprd gpu help] → [POVB] [partner-blocker][sprd298315][need sprd gpu help, need workaround]
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.
(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.
(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.
Attached file ff2_gl.txt.tar.gz (obsolete) —
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.
If the animation is disabled, will this issue happen?
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.
(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);
(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.
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);
(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
Flags: needinfo?(james.zhang)
The problem is not the size, the problem is the texture is uploaded an empty texture and never get updated.
Flags: needinfo?(james.zhang)
(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?
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?
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
Attached file libEGL_blackbox.log —
Peter, I can reproduce this and this log is after I set debug.egl.trace=1 in build.prop.
Flags: needinfo?(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);
Flags: needinfo?(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
Assignee: jason.liu → andrew.wu
Attached file ff.txt.tar.gz (obsolete) —
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.
Flags: needinfo?(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.
Flags: needinfo?(pchang)
Attached file ff.txt.tar.gz (obsolete) —
post again
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
Attached file ff.txt —
post the original log
Attachment #8423648 - Attachment is obsolete: true
Attachment #8423678 - Attachment is obsolete: true
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.
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);
(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
Attachment #8417018 - Attachment is obsolete: true
Attached file ff2_gl.txt.tar.gz (obsolete) —
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);
Attachment #8424546 - Attachment is obsolete: true
Attached file ff2_gl.txt —
(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.
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?
Flags: needinfo?(pchang)
Additional to comment 57. The blackbox in Everything.me page and Second page could be caused by different error.
(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?
Flags: needinfo?(pchang)
Blocks: 1012551
Attached file 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.
Attached file ff.txt —
The original log of last comment
Flags: needinfo?(ttsai)
Flags: needinfo?(styang)
Flags: needinfo?(pchang)
Flags: needinfo?(kli)
Flags: needinfo?(kkuo)
Whiteboard: [POVB] [partner-blocker][sprd298315][need sprd gpu help, need workaround] → [partner-blocker][sprd298315]
Can we workaround for this issue, re-upload texture patch?
(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
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
Attached file 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
Attached file ff_home4.txt —
Single icon on third desktop. Pattern 2, texture 1 is the black block, upload by glEGLImageTargetTexture2DOES, then deleted by glDeleteTextures
Attached file 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.
Flags: needinfo?(kli)
Flags: needinfo?(sotaro.ikeda.g)
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.
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.
Flags: needinfo?(sotaro.ikeda.g)
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.
Can someone test if attachment 8431770 [details] [diff] [review] fix the problem?
Sotaro, I will try this patch. Thank you.
(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.
Flags: needinfo?(sotaro.ikeda.g)
Flags: needinfo?(fabrice)
Sotaro, your patch is OK for this bug, but it can't fix Bug 1012551. Can you help to take a look?
Stealing this bug.
Assignee: andrew.wu → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
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.
Attachment #8431770 - Flags: review?(nical.bugzilla)
(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.
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 <<<<
status-b2g-v1.3T: --- → affected
Flags: needinfo?(sotaro.ikeda.g)
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?
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(james.zhang)
Is there a concrete STR to cause the crash?
It might be possible that v1.3T's TextureHost and GrallocBufferActor are not robust enough to ipc Channel error.
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.
Depends on: 966446
Flags: needinfo?(james.zhang)
James, can you apply Bug 966446 fix? It might fix the crash in Comment 80.
Flags: needinfo?(james.zhang)
OK, we will run monkey test to verify.
Flags: needinfo?(james.zhang)
(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
Flags: needinfo?(ying.xu)
(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
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
Flags: needinfo?(kkuo)
We will land bug 966446 and this bug patch today and run monkey test to verify.
Flags: needinfo?(styang)
Sotaro, can you land this bug patch? Today monkey test is OK with this bug patch.
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?
(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.
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.
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
git log | grep -i adreno And I found 16 commit. 1. commit 165c49b722d1ec321959b2b048072b68ce33e3f2 Author: Jeff Muizelaar <jmuizelaar@mozilla.com> 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 <bjacob@mozilla.com> 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 <bjacob@mozilla.com> 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 <b56girard@gmail.com> 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 <b56girard@gmail.com> 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 <jgilbert@mozilla.com> 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 <chrislord.net@gmail.com> 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 <chrislord.net@gmail.com> 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 <snorp@snorp.net> 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 <vladimir@pobox.com> 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 <bjacob@mozilla.com> 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 <bjacob@mozilla.com> 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 <bjacob@mozilla.com> 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 <bjacob@mozilla.com> Date: Mon Apr 30 17:43:12 2012 -0400 Bug 736123 - blacklist Adreno renderers for WebGL - r=joe 15. commit fa376f2332b73a10ad58870962741433c116e893 Author: George Wright <gwright@mozilla.com> 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 <b56girard@gmail.com> 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 <george@mozilla.com> 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
Nical, Comment 93 is enough answer to your question?
Flags: needinfo?(nical.bugzilla)
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)
Attachment #8431770 - Flags: review?(nical.bugzilla) → review+
Flags: needinfo?(nical.bugzilla)
fabrice seems away until june/17.
Keywords: checkin-needed
Whiteboard: [partner-blocker][sprd298315] → [partner-blocker][sprd298315][only-b2g-v1.3T]
(In reply to Sotaro Ikeda [:sotaro] from comment #99) > fabrice seems away until june/17. Anybody has v1.3t merge permission?
Flags: needinfo?(styang)
Flags: needinfo?(pchang)
(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.
Flags: needinfo?(ttsai)
Flags: needinfo?(styang)
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.
(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.
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.
(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?
(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.
(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
(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.
This bug exist on v1.3 and v1.3T. It might be better to land also to v1.3.
(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 on attachment 8431770 [details] [diff] [review] patch - use gralloc for sync ImageLayer obsolete it. Actual cause of the bug is found on bug 1012551.
Attachment #8431770 - Attachment is obsolete: true
After applying bug 1012551 fix. This bug's problem seems also fixed.
Assignee: sotaro.ikeda.g → nobody
:cjku, if your sides confirmation is also same to Comment 112, please close this bug as dup of bug 1012551.
Flags: needinfo?(cku)
Bug 1012551 Comment 32 is enough to close this bug as dup of bug 1012551.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(cku)
Resolution: --- → DUPLICATE
blocking-b2g: 1.3T+ → ---
Flags: needinfo?(fabrice)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: