Closed
Bug 788411
Opened 12 years ago
Closed 12 years ago
[Otoro] Lock screen arrow animation is not shown
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
People
(Reporter: timdream, Assigned: cjones)
References
Details
(Whiteboard: [WebAPI:P0][LOE:S])
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
STR:
1. Boot up the phone and observe lock screen
Exepected:
1. There should be a semi-transparent arrow travels from the handle to the icons, and iterates
Actual:
1. Nothing
Note:
* Arrow is done with CSS animation, see |@keyframes lockscreen-arrow-left| and -right in lockscreen.css
* Arrow is shown on SGS2 and B2G/Desktop
Assignee | ||
Comment 2•12 years ago
|
||
Thanks for filing this. I noticed this problem when testing something unrelated on desktop-b2g.
Comment 3•12 years ago
|
||
Seems like a usability-related blocker.
cjones, who should own this?
blocking-basecamp: ? → +
Assignee | ||
Comment 4•12 years ago
|
||
dz, if he's around.
Comment 5•12 years ago
|
||
I don't have an otoro, and I can't reproduce this on the Nexus s.
Assignee | ||
Comment 6•12 years ago
|
||
Interesting. Might be a gralloc issue.
Updated•12 years ago
|
Whiteboard: [WebAPI:P0]
Updated•12 years ago
|
Assignee: nobody → jones.chris.g
Comment 7•12 years ago
|
||
I found that if we put some text in the div then the animation becomes visible.
Assignee | ||
Updated•12 years ago
|
Whiteboard: [WebAPI:P0] → [WebAPI:P0][LOE:S]
Assignee | ||
Comment 8•12 years ago
|
||
We're allocating some 12x22 and 50x50 buffers. Not sure which are the arrows. Probably triggering a rounding bug somewhere. Might also be an extreme version of the cache-flush bug, but I never see any pixels so I'd guess this is separate.
Assignee | ||
Comment 9•12 years ago
|
||
This falls into the category of, I don't know why things break below 64x64 and I probably don't want to know.
Attachment #662812 -
Flags: review?(roc)
Assignee | ||
Updated•12 years ago
|
Component: General → Graphics: Layers
Product: Boot2Gecko → Core
Comment on attachment 662812 [details] [diff] [review]
Round gralloc buffer allocations up to a minimum of 64x64
Review of attachment 662812 [details] [diff] [review]:
-----------------------------------------------------------------
How is this safe? Don't we need to adjust texture coordinates when fetching from these buffers?
Assignee | ||
Comment 11•12 years ago
|
||
Comment on attachment 662812 [details] [diff] [review]
Round gralloc buffer allocations up to a minimum of 64x64
It's not, major thinko. I did the testing hack with the thebesbuffer directly.
So currently, on ThebesLayers are set up to handle this case properly. That means we can either
- add this support to all other layer types for all other compositors. Phew!
- make the thebesbuffer rect a minimum of 64x64 (or dimensions multiples of 64, which isn't a bad idea in general to avoid reallocs). Somewhat complicated to handle along with resolution scaling.
- bail out of the gralloc fastpath when the surface dims are < 64x64. This would be fine as long as there weren't a ton of little buffers like this.
Kinda leaning towards the last one. Let me know if you have a strong opinion.
Attachment #662812 -
Flags: review?(roc) → review-
Assignee | ||
Comment 12•12 years ago
|
||
(In reply to Chris Jones [:cjones] [:warhammer] from comment #11)
> - bail out of the gralloc fastpath when the surface dims are < 64x64. This
> would be fine as long as there weren't a ton of little buffers like this.
>
Hm, this workaround has the disadvantage of not actually working. (Even disabling gralloc in TextureImageEGL.) I guess the GL impl doesn't like textures < 64x64.
Assignee | ||
Comment 13•12 years ago
|
||
Guys, this bug might be relevant to your interests.
Whiteboard: [WebAPI:P0][LOE:S] → [WebAPI:P0][LOE:S][caf:needs input]
Assignee | ||
Comment 14•12 years ago
|
||
Nuclear option. It would be extremely sad and embarrassing to have to go here, though.
Attachment #662812 -
Attachment is obsolete: true
Reporter | ||
Comment 15•12 years ago
|
||
(In reply to Chris Jones [:cjones] [:warhammer] from comment #14)
> Created attachment 662845 [details] [diff] [review]
> Gaia workaround
>
> Nuclear option. It would be extremely sad and embarrassing to have to go
> here, though.
That doesn't look too embarrassing to me. Do you want to check-in this in Gaia and continuing fix this bug by testing on an old Gaia?
Assignee | ||
Comment 16•12 years ago
|
||
Only the width needs to be <= 64.
Assignee | ||
Comment 17•12 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #15)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #14)
> > Created attachment 662845 [details] [diff] [review]
> > Gaia workaround
> >
> > Nuclear option. It would be extremely sad and embarrassing to have to go
> > here, though.
>
> That doesn't look too embarrassing to me. Do you want to check-in this in
> Gaia and continuing fix this bug by testing on an old Gaia?
It's pretty bad. I have another workaround/~fix for general web content (thebes layers); let's see how that one goes. It'll still leave <canvas> and <video> below 64x64 in the lurch, but let's hope they're uncommon.
A vendor fix is also possible.
Assignee | ||
Comment 18•12 years ago
|
||
Doesn't help <canvas> or <video>, and doesn't make me very happy, but those are other issues to prioritize. (Excepting me being happy.)
This is a fairly reasonably thing to do when allocating gfx surfaces, though likely redundant with most gfx allocators we'll see.
Maybe we can get a vendor fix.
Attachment #662861 -
Flags: review?(roc)
Attachment #662861 -
Flags: review?(roc) → review+
Comment 19•12 years ago
|
||
(In reply to Chris Jones [:cjones] [:warhammer] from comment #8)
> Might also be an extreme version of the cache-flush bug, but I never
> see any pixels so I'd guess this is separate.
Globally disabling all pmem caching per https://bugzilla.mozilla.org/show_bug.cgi?id=784244#c42 does not bring the arrows back so definitely a separate issue.
Comment 20•12 years ago
|
||
Interestingly enough, this works fine with Hardware composing (WIP)
Comment 21•12 years ago
|
||
So my best guess is the problem is happening in the GPU composition phase
Assignee | ||
Comment 22•12 years ago
|
||
(In reply to Diego Wilson from comment #20)
> Interestingly enough, this works fine with Hardware composing (WIP)
Oh, interesting. Thanks for checking.
I'm going to open a new bug to track a possible fix for canvas and video. If that's hwcompositor, which should be a 99.9% workaround, that's good enough for me for v1.
Whiteboard: [WebAPI:P0][LOE:S][caf:needs input] → [WebAPI:P0][LOE:S]
Assignee | ||
Comment 23•12 years ago
|
||
Assignee | ||
Comment 24•12 years ago
|
||
Filed bug 792966.
Comment 25•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
You need to log in
before you can comment on or make changes to this bug.
Description
•