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 objects
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 crashe
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 us
On Thu, Apr 21, 2016, at 12:24 PM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva
> wrote:
> > Fallible construction (even with a way to report failure) is annoying if
> > only because the object's destructor has to account for the possible
>
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. S
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, a...@im
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
Hi dev-platform,
Heads up: I just landed on Inbound a patch that gives nsIntPoint and
nsIntRect the same treatment I gave to nsIntSize: these two classes are now
typedefs of mozilla::gfx::IntPoint and mozilla::gfx::IntRect, which means
that they can't be forward-declared as they used to, but other
On Fri, Mar 27, 2015 at 10:50 PM, Jet Villegas
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
>
> Thanks!
>
>
I haven'
The first part just landed on inbound (Bug 1132854).
On Fri, Mar 27, 2015 at 10:28 PM, Robert O'Callahan
wrote:
> Sounds good. But, is gfx::IntSize going to get a "ToAppUnits" method like
> nsIntSize has?
>
>
The method:
nsIntSize::ToAppUnits(nscoord aAppUnitsPerPixel) const
was replaced by a f
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 have
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 i
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).
http://perf.snarkfest.net/compare-talos/?oldRevs=56492f7244
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 wrote:
> On Thu, Oct 09, 2014 at 11:18:28PM -0700, Robert O'
Sorry, my example was not clear enough. The issue with using namespace +
unifoed builds is that the using namespace declaration applies to all (or
most) of the headers included in the unified translation unit. So using
namespace mozilla at the top of each .cpp is harmless until we include
third par
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=40010766&tree=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
pi
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 w
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 11:0
>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 g
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
On Sat, Aug 24, 2013 at 9:19 PM, 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 set in Windo
On Tue, Jun 18, 2013 at 3:07 PM, Gavin Sharp wrote:
> If we design it properly this shouldn't be a huge issue (and users
> disabling the feature probably won't be necessary). This isn't
> something we'd provide UI for, certainly.
>
Then we should really measure network traffic impact and take it
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
b
On 08/08/2012 04:32 PM, Justin Lebar wrote:
So I have this scripts that gives for each header the number of translation
units that use it, here is part of the output (i skipped the headers
included in less than 9 TUs) from a week ago (after dzbarsky's patch):
http://pastebin.mozilla.org/1745141
eaders that are included way too much.
Nicolas Silva
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 08/08/2012 02:27 PM, Benjamin Smedberg wrote:
On 8/8/2012 2:09 PM, Nicolas Silva wrote:
Hi dev-platform,
I spent some time looking at include dependencies lately, and I think
it is an area where we can improve our code without too much effort.
Bad include dependencies lead to slower
efPtr and enums described in the MDN
page) should be documented in the coding style guide as well?
Any thoughts?
Nicolas Silva
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
28 matches
Mail list logo
