On Thu, Jun 30, 2016, at 04:35 PM, smaug wrote:
> Not sure if this matters here, but cycle collector doesn't really retain
> objects. Sure, we could explicitly clear so called jsholders, so that
> C++->JS
> edges are manually cut. But in general, CC doesn't know about a cycle
> collectable
Hi dev-platform,
We had a session about shutdown problems during the London workweek. I
did a writeup of what was discussed and as it grew into a large-ish
piece, I put it in a wiki page (instead of the email I intended to send
initially) [1].
There's been a lot of work on reducing shutdown
Your example is suffering from the fact that PR_CreateThread is taking
as parameter an object that is half-initialized, and then continues
constructing it. I believe this to be a poor design and that
unfortunately leaks into the creating of nsThread.
In such a situation I would personally still
r 21, 2016, at 12:24 PM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva <nical.si...@gmail.com>
> wrote:
> > Fallible construction (even with a way to report failure) is annoying if
> > only because the object's destructor has to account for the po
Fallible construction (even with a way to report failure) is annoying if
only because the object's destructor has to account for the possible
invalid states. I much prefer having a static creation method that will
only instantiate the object in case of success, and mark the constructor
protected.
Re-re-ping.
Being able to use a more recent standard library would simplify a lot of
things on our end. For example updating 3rd party libraries such as
skia, which depends on a modern stl, is a pain, and there are plenty of
other examples.
Cheers,
Nical
On Mon, Apr 4, 2016, at 07:33 PM,
I would like to add to what Mason already said about GPU painting. If
one thing is clear, it's that the GPU (as in the many combinations of
hardware and drivers out there) is not a reliable platform, especially
with gecko's current architecture. We get driver bugs for the simplest
things we do and
The first part just landed on inbound (Bug 1132854).
On Fri, Mar 27, 2015 at 10:28 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
Sounds good. But, is gfx::IntSize going to get a ToAppUnits method like
nsIntSize has?
The method:
nsIntSize::ToAppUnits(nscoord aAppUnitsPerPixel) const
was
On Fri, Mar 27, 2015 at 10:50 PM, Jet Villegas jville...@mozilla.com
wrote:
Probably safe for the integer types, but can we add strong assertions when
converting from Thebes and Moz2D floats? Bugs like this one are tough to
debug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1091709
As many of you know, the introduction of Moz2D a while ago added new size,
point and rect classes which are equivalent* to the ones that already
existed in tree (nsIntSize, etc.).
Juggling back and forth between the Moz2D classes and their thebes
equivalent is pretty annoying and until now we
Tiling is in a usable state (modulo some reftest failures), but I
haven't tried to run talos with tiling enabled yet. We'll probably see
the benefit of tiling when we enable APZ (which I don't know the state
of on Linux). We can also enable OMTA but I haven't tried to run tests
with it or dogfood
Hi all,
I am giving the heads up that Off-main-thread compositing (OMTC) will soon
be enabled on Linux and that there are some expected talos regressions.
In particular, a fairly big one in tp5o_scroll (see the compare-talos link
below).
In the mean time we should really detect hidpi screens and default to an
appropriate scale.
The current scale is a terrible experience on a hidpi screen. I filed bug
1081142.
Cheers,
Nical
On Fri, Oct 10, 2014 at 8:39 AM, Mike Hommey m...@glandium.org wrote:
On Thu, Oct 09, 2014 at 11:18:28PM
Now that we have unified builds, writing using namespace in the global
scope of a .cpp file is almost as bad as writing it in a header. Regularly
build errors show up like this one:
https://tbpl.mozilla.org/php/getParsedLog.php?id=40010766tree=Try
What's awesome about these errors is that they
We are working on getting OMTC to perform well on Windows. D3D11 OMTC may
not be too far off, D3D9 will have to wait for tiling to be ready though.
On Linux there are a few glitches here and there and If we want to ship it
we'll have to investigate performance and probably implement texture from
With OMTC these days the Layer classes don't hold any logic. All the fancy
stuff goes into classes inheriting from CompositableClient (and
CompositableHost on the compositor side). While Layer classes can only be
manipulated from the main thread and use the PLayerTransaction IPDL
protocol to sync
I do appreciate the fact that it reduces complexity (in addition to less
state changes).
I agree that the decision of dedicating resources on that rather than on
other high priority projects that are in the pipes should be motivated by
some numbers.
Cheers,
Nical
On Thu, Oct 10, 2013 at
From an API/feature point of view the partial buffer swap does not sound
like a bad idea, especially since, as Mat said, the OMTC BasicLayers will
need something along these lines to work efficiently.
One thing to watch out for, though, is that it is the kind of fine tuning
that, I suspect, will
FWIW, I like to write both virtual and MOZ_OVERRIDE.
I care a lot about always using MOZ_OVERRIDE when applicable. For virtual
(when MOZ_OVERRIDE is present) I suppose it is more of a matter of tastes.
Always explicitly writing both virtual and MOZ_OVERRIDE is a simpler rule
than marking virtual
On Sat, Aug 24, 2013 at 9:19 PM, garys...@gmail.com wrote:
I can't reliably reproduce the problem, it just seems to happen Most of
my corruption is on the chrome. It gets completely or partially overlayed
with blocks of color. Of interest might be the fact that the color is
whatever color
I feel somewhat uneasy about the idea that thumbnails generate more network
traffic. It would be great to at least throttle that when connectivity is
bad, or when the the user's data plan bill could suffer from it (not sure
how to detect/address something like that). If nothing else, users should
21 matches
Mail list logo
