Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HWA and OMTC on Linux

465 views
Skip to first unread message

Nicholas Cameron

unread,
Nov 6, 2013, 7:24:13 PM11/6/13
to dev-platform
Currently on Linux our only 'supported' graphics backend is the
main-thread software backend (basic layers). It is possible to use the
main-thread OpenGL backend using the 'layers.acceleration.force-enabled'
pref, and to use OpenGL with off-main-thread compositing using that pref
and 'layers.offmainthreadcomposition.enabled'. The former works pretty
well, if your drivers are cooperative, the latter has some issues (see
the list of bugs blocking bug 722012 for details) and requires the same
cooperative drivers as main-thread.

Our goal is (basically) to be OMTC everywhere (all backends, all
platforms) and remove (nearly) all of our main thread compositing code.
We would like to remove the main thread OpenGL code (bug 924403). Long
term, keeping it is not an option. We would like to remove it now
because it is making other graphics work much more difficult. The only
platform where this is an issue is Linux (all other platforms which
support OpenGL are already using OMTC).

Some things that make this interesting:

1) Software OMTC is not ready yet (bug 865104), it is not likely to be
ready _very_ soon, but it shouldn't be too long either (I would guess a
couple of months).

2) Unlike other platforms, OMTC on Linux requires an environment
variable (MOZ_USE_OMTC or MOZ_OMTC_ENABLED) which determines if we
initialise X for multiple threads
(http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#l3480).
We have to do this early in startup which is why we can't use a pref.
This has a performance impact for all users (whether they get OMTC or
not) of ~5%.

3) For nightly users, we initialise X for multiple threads in any case
so that e10s works.

4) We do not want (non-nightly) users who do not use OMTC to pay the
cost of multi-threaded X.

5) We would love to spend time making OMTC OpenGL on Linux work
perfectly, but it is not a priority for the graphics team due to the low
number of users. We always hope to get community involvment here, but it
has been patchy in the past. (OMTC OpenGL on Mac, Android, and Firefox
OS works well and is the platform default).

After removing MT OGL, our proposal is that Linux users on nightly or
who manually set MOZ_USE_OMTC will get OMTC OpenGL. That means they will
get the same(-ish) performance, but a possibly worse experience. Other
Linux users will get main thread basic layers, whether they force on HWA
or not. Their performance will be degraded (sometimes), but the rest of
the experience should not (this is the current default configuration for
Linux). (To clarify, we will let this change ride the trains, so when I
say non-nightly users, that will be after the relevant uplift).

In the long term, OMTC basic layers will be the default for Linux and
forcing HWA will give OpenGL OMTC as expected. The environment variable
will be un-necessary because we will always initialise X for multiple
threads.

So, does anyone have any objections to this plan? Or ways we could do
this better? If you use HWA please be aware of these changes and report
any bugs you find. And a heads up that we might be seeing a few bugs
filed around this by users when it happens and at subsequent uplifts.

Thanks, Nick

Robert O'Callahan

unread,
Nov 6, 2013, 9:41:01 PM11/6/13
to Nicholas Cameron, dev-platform
Sounds good to me!

Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w

Henri Sivonen

unread,
Nov 7, 2013, 6:49:46 AM11/7/13
to Nicholas Cameron, dev-platform
On Thu, Nov 7, 2013 at 2:24 AM, Nicholas Cameron <ncam...@mozilla.com> wrote:
> In the long term, OMTC basic layers will be the default for Linux and
> forcing HWA will give OpenGL OMTC as expected.

Do I understand correctly that all these users will get OMTC basic
layers as the long-term solution?
* Don't have 3D drivers on a pre-llvmpipe system (e.g. Ubuntu 12.04 LTS)
* Don't have 3D drivers but have Unity or Gnome 3 running on llvmpipe
* Have 3D drivers capable of running Unity or Gnome 3 but blocklisted
by Firefox (e.g. VirtualBox OpenGL pass-through)

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/

Karl Tomlinson

unread,
Nov 7, 2013, 4:19:45 PM11/7/13
to
Nicholas Cameron writes:

> Currently on Linux our only 'supported' graphics backend is the
> main-thread software backend (basic layers).

FWIW basic layers is predominantly GPU-based compositing
(not-softwared) on most X11 systems.

> 5) We would love to spend time making OMTC OpenGL on Linux work
> perfectly, but it is not a priority for the graphics team due to
> the low number of users.

I would have assumed the number of Linux/X11 users is greater
than the number of Linux/Android users.

> After removing MT OGL, our proposal is that Linux users on nightly
> or who manually set MOZ_USE_OMTC will get OMTC OpenGL. That means
> they will get the same(-ish) performance, but a possibly worse
> experience. Other Linux users will get main thread basic layers,
> whether they force on HWA or not. Their performance will be
> degraded (sometimes), but the rest of the experience should not
> (this is the current default configuration for Linux).

The most significant performance degrading I expect here is for
users that want to use WebGL maps or games. Flicking the pref
for OpenGL layers is the current workaround a get reasonable
performance there.

The new workaround will also require setting an environment variable
off nightly, but that's not so much more awkward than about:config.

> So, does anyone have any objections to this plan? Or ways we could
> do this better? If you use HWA please be aware of these changes
> and report any bugs you find. And a heads up that we might be
> seeing a few bugs filed around this by users when it happens and
> at subsequent uplifts.

Will any MoCo developers be permitted to spend some time fixing
these or the already-known issues?

If MoCo is prepared to use some of the developer time saved
through removing MT OGL on fixing these issues, then that
hopefully will be a net positive move.

How about first moving Nightly OGL users to OMTC, and then remove
MT OGL after the next uplift?

Then we have some time to discover whether there are any
show-stopper OMTC issues, and we reduce the time frame for other
branches between paying the price and reaping the returns.

Andreas Gal

unread,
Nov 7, 2013, 4:24:22 PM11/7/13
to Karl Tomlinson, dev-pl...@lists.mozilla.org

On Nov 7, 2013, at 1:19 PM, Karl Tomlinson <moz...@karlt.net> wrote:

> Nicholas Cameron writes:
>
>> Currently on Linux our only 'supported' graphics backend is the
>> main-thread software backend (basic layers).
>
> FWIW basic layers is predominantly GPU-based compositing
> (not-softwared) on most X11 systems.
>
>> 5) We would love to spend time making OMTC OpenGL on Linux work
>> perfectly, but it is not a priority for the graphics team due to
>> the low number of users.
>
> I would have assumed the number of Linux/X11 users is greater
> than the number of Linux/Android users.

Please think about the potential user base, not just current user base. The potential user base of Linux users is tiny, and mostly stagnant. The potential user base of mobile Linux (Android, FFOS) is massive, and growing explosively.

>
>> After removing MT OGL, our proposal is that Linux users on nightly
>> or who manually set MOZ_USE_OMTC will get OMTC OpenGL. That means
>> they will get the same(-ish) performance, but a possibly worse
>> experience. Other Linux users will get main thread basic layers,
>> whether they force on HWA or not. Their performance will be
>> degraded (sometimes), but the rest of the experience should not
>> (this is the current default configuration for Linux).
>
> The most significant performance degrading I expect here is for
> users that want to use WebGL maps or games. Flicking the pref
> for OpenGL layers is the current workaround a get reasonable
> performance there.
>
> The new workaround will also require setting an environment variable
> off nightly, but that's not so much more awkward than about:config.
>
>> So, does anyone have any objections to this plan? Or ways we could
>> do this better? If you use HWA please be aware of these changes
>> and report any bugs you find. And a heads up that we might be
>> seeing a few bugs filed around this by users when it happens and
>> at subsequent uplifts.
>
> Will any MoCo developers be permitted to spend some time fixing
> these or the already-known issues?

Its not a priority to fix Linux/X11. We will happily take contributed patches, and people are welcome to fix issues they see, as long its not at the expense of the things that matter.

>
> If MoCo is prepared to use some of the developer time saved
> through removing MT OGL on fixing these issues, then that
> hopefully will be a net positive move.
>
> How about first moving Nightly OGL users to OMTC, and then remove
> MT OGL after the next uplift?

The old OGL code is a tremendous maintenance nightmare and is actively hurting our ability to make progress on the OMTC code. We would like to delete it asap.

Andreas

>
> Then we have some time to discover whether there are any
> show-stopper OMTC issues, and we reduce the time frame for other
> branches between paying the price and reaping the returns.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Karl Tomlinson

unread,
Nov 7, 2013, 4:48:42 PM11/7/13
to
Andreas Gal writes:

> Its not a priority to fix Linux/X11. We will happily take
> contributed patches, and people are welcome to fix issues they
> see, as long its not at the expense of the things that matter.

Do bugs in B2G Desktop on Linux/X11 matter?

I assume glitches and perf issues that are not on the device don't
really matter. How about crashes and security bugs?

Andreas Gal

unread,
Nov 7, 2013, 4:52:32 PM11/7/13
to Karl Tomlinson, dev-pl...@lists.mozilla.org
Nobody said Linux/X11 doesn't matter. The proposal was to focus on OMTC on all platforms, including Linux/X11.

Andreas

Karl Tomlinson

unread,
Nov 7, 2013, 5:26:47 PM11/7/13
to
Andreas Gal writes:

> On Nov 7, 2013, at 1:48 PM, Karl Tomlinson <moz...@karlt.net> wrote:
>
>> Andreas Gal writes:
>>
>>> Its not a priority to fix Linux/X11. We will happily take
>>> contributed patches, and people are welcome to fix issues they
>>> see, as long its not at the expense of the things that matter.
>>
>> Do bugs in B2G Desktop on Linux/X11 matter?
>>
>> I assume glitches and perf issues that are not on the device
>> don't really matter. How about crashes and security bugs?
>
> Nobody said Linux/X11 doesn't matter. The proposal was to focus
> on OMTC on all platforms, including Linux/X11.

I assume games and maps and WebGL matter.
The current direction for WebGL on Linux/X11 seems to be assuming
that OGL will be the solution.

The comments thus far in this thread imply that OGL-OMTC-Linux-X11
doesn't matter. If that is the case, then we need to find another
solution for WebGL. However, OGL-OMTC layers is likely the best
solution for WebGL, and not necessarily more work.

And if OGL-OMTC-Linux-X11 doesn't matter for Firefox, then how
much is B2G Desktop used on Linux? Even if only crashes on Linux
B2G Desktop matter, then OGL-OMTC-Linux-X11 Firefox will benefit
from sharing the same code, and benefits flow the other way too.

Benoit Jacob

unread,
Nov 7, 2013, 5:43:50 PM11/7/13
to Karl Tomlinson, dev-platform
(Not replying to anyone in particular, just replying to the lastest email
in this thread at this point: ) Let's not transform the original
conversation here, which was purely a technical conversation about
improving the way we do compositing on Linux, into a prioritization
conversation, which would not belong on dev-platform.

One data point that Karl provided here is purely technical and needs to be
taken into account in this technical conversation well before one would
start talking priorities: newer types of Web content, e.g. WebGL, may mean
that not having OpenGL compositing may become less and less viable going
forward.

Benoit


2013/11/7 Karl Tomlinson <moz...@karlt.net>

Robert Kaiser

unread,
Nov 7, 2013, 8:12:09 PM11/7/13
to
Nicholas Cameron schrieb:
> Our goal is (basically) to be OMTC everywhere


I have been using OMTC on Linux for a while (with both prefs on,
actually) and with the exception of
https://bugzilla.mozilla.org/show_bug.cgi?id=934250 everything works
really fine (but then, I'm on the newest kernel/driver and Xorg versions
and am using the open Intel drivers).
> 3) For nightly users, we initialise X for multiple threads in any case
> so that e10s works.

Ah, so that is the reason why OMTC is now always on for me, no matter if
I use the env var or not.
That said, I thought we are targeting to get e10s enabled at some point
anyhow, so maybe we should just take this hit and be done with it.

> 4) We do not want (non-nightly) users who do not use OMTC to pay the
> cost of multi-threaded X.

As said above, I wonder if we actually should do that and be done with it.

> 5) We would love to spend time making OMTC OpenGL on Linux work
> perfectly, but it is not a priority for the graphics team due to the low
> number of users. We always hope to get community involvment here, but it
> has been patchy in the past.

Maybe we need to communicate better that we need help there?

KaiRo

L. David Baron

unread,
Nov 7, 2013, 6:06:26 PM11/7/13
to Andreas Gal, dev-pl...@lists.mozilla.org, Karl Tomlinson
On Thursday 2013-11-07 13:24 -0800, Andreas Gal wrote:
> On Nov 7, 2013, at 1:19 PM, Karl Tomlinson <moz...@karlt.net> wrote:
> > Will any MoCo developers be permitted to spend some time fixing
> > these or the already-known issues?
>
> Its not a priority to fix Linux/X11. We will happily take contributed patches, and people are welcome to fix issues they see, as long its not at the expense of the things that matter.

I think having Linux/X11 be working and in good shape is important
for attracting contributors to the Mozilla project, particularly
those who write code. (Though I haven't seen recent data on OS use
of Mozilla contributors who aren't paid to work on Mozilla. I'd be
very surprised if it wasn't a much higher proportion of developers
than users, though.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)
signature.asc

Andreas Gal

unread,
Nov 7, 2013, 8:37:13 PM11/7/13
to L. David Baron, dev-pl...@lists.mozilla.org, Karl Tomlinson

On Nov 7, 2013, at 3:06 PM, "L. David Baron" <dba...@dbaron.org> wrote:

> On Thursday 2013-11-07 13:24 -0800, Andreas Gal wrote:
>> On Nov 7, 2013, at 1:19 PM, Karl Tomlinson <moz...@karlt.net> wrote:
>>> Will any MoCo developers be permitted to spend some time fixing
>>> these or the already-known issues?
>>
>> Its not a priority to fix Linux/X11. We will happily take contributed patches, and people are welcome to fix issues they see, as long its not at the expense of the things that matter.
>
> I think having Linux/X11 be working and in good shape is important
> for attracting contributors to the Mozilla project, particularly
> those who write code. (Though I haven't seen recent data on OS use
> of Mozilla contributors who aren't paid to work on Mozilla. I'd be
> very surprised if it wasn't a much higher proportion of developers
> than users, though.)

I don't think anyone disagrees with you here, except if you are saying that somehow keeping the non-OMTC Linux code is critical to attract contributors to Mozilla. I don't think thats the case and I don't think you are trying to say that. Thats what the post was all about. We want to get rid of the old non-OMTC code because its blocking making OMTC better everywhere, including Linux.

Andreas

Karl Tomlinson

unread,
Nov 7, 2013, 9:37:49 PM11/7/13
to
Andreas Gal writes:

> On Nov 7, 2013, at 3:06 PM, "L. David Baron" <dba...@dbaron.org> wrote:
>
>> On Thursday 2013-11-07 13:24 -0800, Andreas Gal wrote:
>>> On Nov 7, 2013, at 1:19 PM, Karl Tomlinson <moz...@karlt.net> wrote:
>>>> Will any MoCo developers be permitted to spend some time fixing
>>>> these or the already-known issues?
>>>
>>> Its not a priority to fix Linux/X11. We will happily take
>>> contributed patches, and people are welcome to fix issues they
>>> see, as long its not at the expense of the things that matter.
>>
>> I think having Linux/X11 be working and in good shape is important
>> for attracting contributors to the Mozilla project, particularly
>> those who write code.

> I don't think anyone disagrees with you here, except if you are
> saying that somehow keeping the non-OMTC Linux code is critical
> to attract contributors to Mozilla. I don't think thats the case
> and I don't think you are trying to say that. Thats what the
> post was all about. We want to get rid of the old non-OMTC code
> because its blocking making OMTC better everywhere, including
> Linux.

It is a major discouragement to contributors when their efforts
are regressed or discarded because they are in the way and don't
matter. It wouldn't be reasonable to continue to expect
contributions after doing this.

Throwing out non-OMTC OGL without putting effort into making OMTC
OGL as functional would be doing just that.

This is what happened with native notifications, and I hope we
don't have the same situation again here.

L. David Baron

unread,
Nov 8, 2013, 3:48:59 AM11/8/13
to Andreas Gal, dev-pl...@lists.mozilla.org, Karl Tomlinson
On Thursday 2013-11-07 17:37 -0800, Andreas Gal wrote:
>
> On Nov 7, 2013, at 3:06 PM, "L. David Baron" <dba...@dbaron.org> wrote:
>
> > On Thursday 2013-11-07 13:24 -0800, Andreas Gal wrote:
> >> On Nov 7, 2013, at 1:19 PM, Karl Tomlinson <moz...@karlt.net> wrote:
> >>> Will any MoCo developers be permitted to spend some time fixing
> >>> these or the already-known issues?
> >>
> >> Its not a priority to fix Linux/X11. We will happily take contributed patches, and people are welcome to fix issues they see, as long its not at the expense of the things that matter.
> >
> > I think having Linux/X11 be working and in good shape is important
> > for attracting contributors to the Mozilla project, particularly
> > those who write code. (Though I haven't seen recent data on OS use
> > of Mozilla contributors who aren't paid to work on Mozilla. I'd be
> > very surprised if it wasn't a much higher proportion of developers
> > than users, though.)
>
> I don't think anyone disagrees with you here, except if you are saying that somehow keeping the non-OMTC Linux code is critical to attract contributors to Mozilla. I don't think thats the case and I don't think you are trying to say that. Thats what the post was all about. We want to get rid of the old non-OMTC code because its blocking making OMTC better everywhere, including Linux.

Nope, I'm definitely not trying to say anything about which set of
code we're using on Linux; I'm just saying that having Linux/X11 as
a first tier platform is important for attracting contributors.
signature.asc

Robert O'Callahan

unread,
Nov 8, 2013, 4:12:02 AM11/8/13
to Karl Tomlinson, dev-pl...@lists.mozilla.org
On Thu, Nov 7, 2013 at 6:37 PM, Karl Tomlinson <moz...@karlt.net> wrote:

> It is a major discouragement to contributors when their efforts
> are regressed or discarded because they are in the way and don't
> matter. It wouldn't be reasonable to continue to expect
> contributions after doing this.
>

Yes but ... the flip side is that just because someone contributed
something doesn't mean we should commit to supporting and shipping that
code indefinitely.

Throwing out non-OMTC OGL without putting effort into making OMTC
> OGL as functional would be doing just that.
>

Hmm. In what way is OMTC OGL less functional than main-thread OGL, on
Linux/X11, today?

Nicholas Cameron

unread,
Nov 10, 2013, 4:03:26 PM11/10/13
to
Yes, all Linux users no matter what their graphics setup will get OMTC basic layers in the long term.

Nicholas Cameron

unread,
Nov 10, 2013, 4:05:09 PM11/10/13
to
On Friday, November 8, 2013 10:19:45 AM UTC+13, Karl Tomlinson wrote:

> Then we have some time to discover whether there are any
>
> show-stopper OMTC issues, and we reduce the time frame for other
>
> branches between paying the price and reaping the returns.

We already paying the price on nightly for e10s.

Nicholas Cameron

unread,
Nov 10, 2013, 4:13:08 PM11/10/13
to
On Friday, November 8, 2013 3:37:49 PM UTC+13, Karl Tomlinson wrote:
>
>
> It is a major discouragement to contributors when their efforts
>
> are regressed or discarded because they are in the way and don't
>
> matter. It wouldn't be reasonable to continue to expect
>
> contributions after doing this.
>
>
Much code from MT OpenGL found its way into OMTC OpenGL, so I would not say we are throwing it away. Personally, if I had written that code, I would not feel sad.

Are you thinking of anyone in particular? I wasn't aware of anyone who had contributed big chunks to the OGL backend, but if there is we should get in contact, maybe explain things and try and persuade them to keep contributing!
>
> Throwing out non-OMTC OGL without putting effort into making OMTC
>
> OGL as functional would be doing just that.
>
>
One reason I would like to turn off MT OpenGL sooner rather than later is to get more motivation around making OMTC OpenGL better - either from volunteers or management.

I hope I didn't give the impression that OMTC OpenGL is really bad. On the graphics side (and modulo unknown bugs) it is as good as MT (afterall, we use it on Mac, b2g, and Android, so we should notice bugs). The integration with Linux is not perfect, but it is really not so bad. I left it on for a month by accident and didn't notice, many users are using it already by choice (e.g., KaiRo, above).


Nicholas Cameron

unread,
Nov 10, 2013, 4:15:40 PM11/10/13
to
On Friday, November 8, 2013 10:12:02 PM UTC+13, Robert O'Callahan wrote:
> On Thu, Nov 7, 2013 at 6:37 PM, Karl Tomlinson <moz...@karlt.net> wrote:

> Throwing out non-OMTC OGL without putting effort into making OMTC
>
> > OGL as functional would be doing just that.
>
> >
>
>
>
> Hmm. In what way is OMTC OGL less functional than main-thread OGL, on
>
> Linux/X11, today?
>

Off the top of my head, I think plugins (the same issue we have on Windows with the positioning) and resizing the window are issues. But I haven't tried either in a while and there might be other things too (there are a lot of bugs blocking the Linux/OMTC meta-bug I posted in the first message, but I have not checked how many are still valid).

Karl Tomlinson

unread,
Nov 11, 2013, 4:14:38 PM11/11/13
to
For the sake of WebGL, GL compositing is most likely the preferred
backend for Linux/X11. Basic layers with Render compositing is
available as a fallback for those without sufficient GL support.

Our goal for X11 should be OMTC GL compositing. Adding OMTC
support for X11 basic layers will address some of the issues that
need to be addressed for OMTC X11 GL layers.

With the current state of the code with GL compositing code on
X11, users will usually have better performance with Render
compositing (1).

We should improve the situation with GL compositing, but the
*LayerOGL files are not going to get us closer to our goal.

Given the above, the proposal to move non-nightly users to Render
compositing if MOZ_OMTC_ENABLED is not set, so that *LayerOGL
files can be removed, is sensible. Similarly moving Nightly GL
users to OMTC GL makes sense, if there is going to be any kind of
effort to fix regressions.

If Linux/X11 is a tier 1 platform, then someone needs to be
permitted to fix Linux/X11-only regressions.

Footnote 1:

The situation with GL compositing on X11, even non-OMTC, has
deteriorated into readback sadness. The nail in the coffin was
disabling TextureImageSupportsGetBackingSurface() for an
undiagnosed OMTC, possibly e10s, hang [1], but other changes
(e.g. Azure canvas [2]) had already changed at least some paths
to read back some time ago.

GL layers, OTMC or not, is still faster for WebGL than reading
back to use Render.

[1] http://hg.mozilla.org/mozilla-central/rev/605119645626
[2] http://hg.mozilla.org/mozilla-central/rev/1661cbbc3759

Nicholas Cameron

unread,
Nov 26, 2013, 6:44:19 PM11/26/13
to
This has finally happened. If it sticks, then after this commit (https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=aa0066b3865c) there will be no more main thread OpenGL compositing on any platform. See my blog post (http://featherweightmusings.blogspot.co.nz/2013/11/no-more-main-thread-opengl-in-firefox.html) for details (basically what I proposed at the beginning of this thread).

Benoit Jacob

unread,
Nov 26, 2013, 7:25:53 PM11/26/13
to Nicholas Cameron, dev-platform
Congrats Nick, after all is said and done, this is a very nice milestone to
cross!


2013/11/26 Nicholas Cameron <nick.r....@gmail.com>

Nicholas Cameron

unread,
Nov 27, 2013, 3:47:00 AM11/27/13
to
Thanks Benoit! It is indeed a nice milestone. Congrats are due to nical, Bas, and pretty much all of the graphics team for all the work on the layers refactoring and OMTC.

Milan Sreckovic

unread,
Nov 27, 2013, 10:57:01 AM11/27/13
to Nicholas Cameron, dev-pl...@lists.mozilla.org
Years from now the stories will go... "I had to walk to school through 10ft deep snow, uphill both ways, and when I got there, we had to do OGL compositing on the main thread".

Now, all reading this and running Nightly on Linux, and having layers.acceleration.force-enabled set, please try to break this so that we can find any residual problems :)
--
- Milan

On 2013-11-26, at 18:44 , Nicholas Cameron <nick.r....@gmail.com> wrote:

> This has finally happened. If it sticks, then after this commit (https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=aa0066b3865c) there will be no more main thread OpenGL compositing on any platform. See my blog post (http://featherweightmusings.blogspot.co.nz/2013/11/no-more-main-thread-opengl-in-firefox.html) for details (basically what I proposed at the beginning of this thread).
0 new messages