If there is a Cairo OpenVG backend then we ought to be able to use that to get
a crude performance measure. If we get decent perf improvement there, then it
is probably worth us making an Azure backend. If not then it probably isn't
worth the long term support overhead.
I imagine that having an
On Tuesday, February 26, 2013 8:34:39 AM UTC+13, Jet Villegas wrote:
> AIUI, a key goal of our Layers Refactoring is to significantly reduce the
> cost of standing up new GFx backends (the first new one being D3Dv11.) As
> that progresses, I'd like to see detailed documentation about how new
> b
This sounds like an awful lot of work, a lot more than some glue code and code
deletion. It sounds like you are proposing to make Moz2D pretty much a general
purpose 2D and 3D graphics library, touch (to some effect) the whole of the
graphics code, and switch to using new libraries which have no
On Wednesday, May 1, 2013 7:22:47 PM UTC+12, Andreas Gal wrote:
> On May 1, 2013, at 12:14 AM, Nicholas Cameron
> wrote:
>
>
>
> > This sounds like an awful lot of work, a lot more than some glue code and
> > code deletion. It sounds like you are proposing
On Wednesday, May 29, 2013 9:58:34 AM UTC+12, Jared Wein wrote:
> - Original Message -
>
> > From: "Robert O'Callahan"
>
> > To: "Jonathan Watt"
>
> > Cc: dev-platform@lists.mozilla.org
>
> > Sent: Wednesday, May 22, 2013 10:11:55 PM
>
> > Subject: Re: Extending the text-overflow/ove
On Saturday, June 29, 2013 2:04:58 PM UTC+12, Justin Lebar wrote:
> tl;dr - Changes from bug 820686:
>
>
> 4. Don't put code after MOZ_CRASH() or MOZ_ASSUME_UNREACHABLE(); it just
> gives
> a false sense of security.
>
This appears not to be true. On Try, Windows builds fail if a method e
On Tuesday, July 30, 2013 8:16:48 AM UTC+12, Doug Turner wrote:
> My issue wasn't if we were going to work on the 'off-line' problem or
>
> not. It was mostly around stating we're going to implement
>
> prematurely. It might be I don't really understand what the "Intent to
>
> implement" bl
I experimented with IWYU for gfx/layers. I got decent build time improvements -
around 12.5% (30s out of a 4min build with j1, 7s from 55s for j12) for a
complete rebuild of gfx/layers using Clang on Linux.
The process was far from automatic. I think this is in part because the layers
code has
+1 for always using virtual (useful documentation without having to check the
super class), even with MOZ_OVERRIDE (just style).
Also +1 for /* static */ on method definitions (when they are declared static)
because that is useful information. /* virtual */ on definitions, I don't find
useful b
Yes. One of many mistakes it can helpfully make for you (along with including
impl headers instead of the API ones, only being correct for the current build,
etc.).
I believe you can setup rules to stop it doing this particular thing. But in
general, IWYU is a semi-automatic process and require
I timed builds to see if this makes a significant difference and it did not.
I timed a clobber debug build using clang with no ccache on Linux on a fast
laptop. I timed using a pull from m-c about a week old (I am using this pull
because I have a lot of other stats on it). I then applied bjacob'
I suppose that that metric will be different between compilers (msvc vs gcc vs
clang (which we don't officially build with, but I bet is the easiest to get
the info out of)), and possibly between platforms, versions, etc. I wouldn't be
surprised if the context in which the header is included mak
Hi, I seem to remember reading a post here about no longer exporting headers
during incremental builds, but I couldn't find it.
Anyway, if there is any way at all that we could undo that, it would be
awesome. For me the change means that whenever I change a header file, I have
about a 50% chanc
On Friday, September 20, 2013 12:22:00 PM UTC+12, Gregory Szorc wrote:
> On 9/19/2013 4:56 PM, Nicholas Cameron wrote:
>
> > Hi, I seem to remember reading a post here about no longer exporting
> > headers during incremental builds, but I couldn't find it.
>
> >
Could we run with DEBUG on? We'd index strictly more code (I think) and
sometimes I miss debug-only things.
(One day I would love to get Windows-only stuff indexed, but I guess we have to
wait for Clang to work on Windows for that).
Nick
On Thursday, October 3, 2013 8:33:40 AM UTC+13, Erik Ros
On Friday, October 11, 2013 5:50:05 AM UTC+13, Benoit Girard wrote:
> On Thu, Oct 10, 2013 at 7:59 AM, Andreas Gal wrote:
>
>
>
> > Rationale:
>
> > switching shaders tends to be expensive.
>
> >
>
>
>
> In my opinion this is the only argument for working on this at moment.
>
I think alm
You probably don't want to draw into the layer at all. So the main
thread should have a canvas layer and the worker thread should draw into
a CanvasClient (I think, the canvas layer will have a dummy canvas
client too which doesn't do much). This is similar to how async video
works where it is
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.of
On Friday, November 8, 2013 12:49:46 AM UTC+13, Henri Sivonen wrote:
> On Thu, Nov 7, 2013 at 2:24 AM, Nicholas Cameron wrote:
>
> > In the long term, OMTC basic layers will be the default for Linux and
>
> > forcing HWA will give OpenGL OMTC as expected.
>
>
>
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 nig
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 d
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 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 le
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-
his is a very nice milestone to
>
> cross!
>
>
>
>
>
> 2013/11/26 Nicholas Cameron
>
>
>
> > This has finally happened. If it sticks, then after this commit (
>
> > https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=aa0066b3865c) there
&
I just landed a patch flipping the switch for all Windows users with HWA
(d3d9/10/11) to use off-main-thread compositing. This is a fairly big change to
our rendering pipeline, so if you notice rendering issues on Windows, please
file bugs.
For now, only nightly users will get this change. Ridi
And after only 20 short, but glorious hours, we have turned it off again to
investigate a smorgasbord of talos regressions (bug 946567).
In the meantime, please do help test Windows OMTC by manually setting the
'layers.offmainthreadcomposition.enabled' pref to true.
Cheers, Nick
__
26 matches
Mail list logo
