Closed Bug 741837 Opened 13 years ago Closed 13 years ago

Hook up OMTC for Gonk

Categories

(Firefox OS Graveyard :: General, defect)

All
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Daeken, Assigned: Daeken)

References

Details

Attachments

(1 file, 3 obsolete files)

Attached patch Initial patch (obsolete) (deleted) — Splinter Review
Gonk should be able to utilize the OMTC functionality implemented for Mobile and Desktop Firefox. Attached is an initial patch. There are currently stability issues and no way to fallback to non-OMTC pathways, so this patch should be used purely for testing.
Assignee: nobody → cbrocious
OS: Windows 7 → Gonk
Hardware: x86_64 → All
Attachment #611843 - Attachment is patch: true
Cody, we can land this patch very quickly if we - respect the omtc pref like fennec does, which we need anyway - and obviously, fall back on same-thread compositor when !omtc Getting code in asap means you have less bitrottage to eat, and allows other folks to test much more easily.
This patch adds the preference check, but it still doesn't fall back to non-OMTC pathways when it's not available. In addition, it still has the hard-coded screen size.
Attachment #611843 - Attachment is obsolete: true
Attachment #612202 - Flags: review?(gal)
Comment on attachment 612202 [details] [diff] [review] Patch for OMTC that respects preferences and sets OMTC enabled by default Review of attachment 612202 [details] [diff] [review]: ----------------------------------------------------------------- ::: widget/gonk/nsWindow.cpp @@ +89,5 @@ > // fbs succeeded or failed. > gNativeWindow = new android::FramebufferNativeWindow(); > + > + if (sUsingOMTC) { > + // XXX: We shouldn't need this as it's set by CreateForWindow Whats the right fix for this? @@ +149,5 @@ > + static unsigned char bits2[1 * 1 * 3]; > + nsRefPtr<gfxASurface> targetSurface; > + > + if(sUsingOMTC) > + targetSurface = new gfxImageSurface(bits2, gfxIntSize(1, 1), 1 * 3, What do we use this for? looks pretty hacky
I'm working on a fix for the size right now. We have to assign it to something initially as the window is sized based on this, but I have it resizing based on information from the compositor side now. Should have that rolled into the patch shortly. As for the other targetSurface, there needs to be some surface for BasicLayers to draw to, but it seems that I can create a gfxImageSurface without actually giving it a backing store, which is probably the better approach. Going to test that out now.
Attached patch Fixed previous issues (obsolete) (deleted) — Splinter Review
Size is no longer hard coded, target surface is created once and there's no provided backing store.
Attachment #612202 - Attachment is obsolete: true
Attachment #612202 - Flags: review?(gal)
Attachment #612407 - Flags: review?(gal)
Comment on attachment 612407 [details] [diff] [review] Fixed previous issues Review of attachment 612407 [details] [diff] [review]: ----------------------------------------------------------------- ::: widget/gonk/nsWindow.cpp @@ +104,5 @@ > + if (!sGLContext) { > + LOG("Failed to create GL context for fb, trying /dev/graphics/fb0"); > + > + // We can't delete gNativeWindow. > + Extra space not needed here. @@ +107,5 @@ > + // We can't delete gNativeWindow. > + > + nsIntSize screenSize; > + sFramebufferOpen = Framebuffer::Open(&screenSize); > + gScreenBounds = nsIntRect(nsIntPoint(0, 0), screenSize); All the duplicated code here is a bit ugly and its all slightly different from above. We can fix later I gues. @@ +154,5 @@ > + > + if(sUsingOMTC) > + targetSurface = sOMTCSurface; > + else > + targetSurface = Framebuffer::BackBuffer(); If you move the UsimgOMTC logic into FrameBuffer, you can probably have a simpler interface here @@ +170,3 @@ > > + if (!sUsingOMTC) { > + targetSurface->Flush(); here too
Attachment #612407 - Flags: review?(gal) → review+
Land it. That entire fire needs a little cleanup, but we can leave that for a later exercise. Lets turn this on.
Attached patch Updated to mozilla-inbound (deleted) — Splinter Review
Attachment #612407 - Attachment is obsolete: true
Whoa, um +pref("layers.offmainthreadcomposition.enabled", true); That was meant to be "false", right?
Why not enabled as long it works?
(In reply to Cody Brocious [:Daeken] from comment #0) > Created attachment 611843 [details] [diff] [review] > Initial patch > > There are currently stability issues
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
No longer blocks: omtc
Blocks: omtc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: