Re: Layer Construction for Off Main Thread canvas
On Thu, Oct 31, 2013 at 12:36 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Oct 31, 2013 at 5:28 PM, Kyle Huey m...@kylehuey.com wrote: One thing that's come up that we're not quite how to deal with for OMTcanvas is how to modify GetCanvasLayer. Our problem here is that the context here lives on the worker thread, and presumably we need to construct the layer on the main thread, but creating that layer requires data that also lives on the worker thread. We obviously can't block the main thread on a synchronous call to the worker, and we can't just lock around the values because that will break run to completion semantics on the worker (e.g. if the worker never yields, changes in the canvas size shouldn't take effect). I think the right thing to do is probably to ship the values from the worker to the main thread asynchronously as they are updated on the worker (once the worker yields/etc) and create the layer using those values. How often do we create layers? It would be a shame if rendering straight from the worker to the compositor were blocked by the main thread due to layer creation. Anything else we should be thinking about here? What values do you need from the worker in order to create the layer? Well, at the very least we need the dimensions of the canvas buffer. We need to know if the context is lost too, but that can already happen anytime so that's not too bad. The dimensions live on the worker thread (which can update them) so we need to either lock and read them from the main thread or maintain a separate copy of the dimensions on the main thread and post messages to update them. If we do the first then it's possible for the dimensions the compositor sees to be newer than the last data we pushed to it. If we do the latter then the opposite is possible. Does the compositor care if the layer size and the data we push to it are not in sync? The CanvasLayer also wants the GLContext to do stuff with it. Not sure what we're going to do with that ... It seems to me that we should be able to create a CanvasLayer on the main thread that is sized to the canvas element. Then from the CanvasLayer we get some kind of thread-safe object (analogous to the ImageContainer of an ImageLayer) which can be handed to the worker in the WorkerCanvas. This object would support being one end of the surface stream for WebGL. You would feed a series of surfaces into it which could have different sizes and the compositor will size them to the layer. That sounds reasonable ... it seems like just getting everything set up is the hard part. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Sheriffs] Closure of trunk trees - owners for bugs needed
Hi, good morning. Since the Trees are still closed here is a update as of 0:45am Pacific Time * https://bugzilla.mozilla.org/show_bug.cgi?id=932898 has an owner now * https://bugzilla.mozilla.org/show_bug.cgi?id=932880 Patch landed on inbound and tests are running. Cheers, - Tomcat - Original Message - From: Ed Morley emor...@mozilla.com To: Sheriffs sheri...@mozilla.org, dev.tree-management dev-tree-managem...@lists.mozilla.org, dev.platform dev-platform@lists.mozilla.org Sent: Wednesday, October 30, 2013 7:04:45 PM Subject: [Sheriffs] Closure of trunk trees - owners for bugs needed Hi all! Trunk trees are currently closed [1] - the requirements for reopening are: https://bugzilla.mozilla.org/show_bug.cgi?id=932781#c11 tl;dr we need owners for these bugs: * https://bugzilla.mozilla.org/show_bug.cgi?id=932898 * https://bugzilla.mozilla.org/show_bug.cgi?id=932880 Please can anyone who has any spare cycles take a look! :-) Best wishes, Ed [1] Apart from b2g-inbound, since that doesn't run Windows 7 tests, which are the ones that are being the most problematic. On 30 October 2013 14:09:47, Ed Morley wrote: I've broken the tree closing issues out into https://bugzilla.mozilla.org/show_bug.cgi?id=932781 and pasted the relevant parts of the IRC conversations from last night, because the OOMs are not constrained to that one existing bug it's good to get the IRC chat saved somewhere visible (I've only just managed to piece together what has been tried so far and where we're at). khuey is kindly looking at this some more once he's gotten sorted :-) Ed ___ Sheriffs mailing list sheri...@mozilla.org https://mail.mozilla.org/listinfo/sheriffs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Add-on File Registration PRD
On Thursday, October 31, 2013 2:09:06 AM UTC+2, David E. Ross wrote: This appears to be a total reversal of past Mozilla philosophy, ... Agreed. Central repo and mandatory approval is not what Mozilla is IMO. While there are some gains from such move, I think it hurts freedom and openness more. Essentially the browser has become an operating system, where apps/addons could be installed to it, including malwares. However, consider what happens if Microsoft or Apple would not let any app run unless it's approved on their main desktop OS? Look at the open community response to IOS closed garden. What about companies who have private addons for their own employees which they don't want to share with Mozilla? What about addons which are against some US regulations? can we stop the government from preventing Mozilla approving those? What about addons which are against Mozilla's philosophy? Do we wanna stop those? Would we? This really is a line Mozilla should not cross IMO. Mozilla may provide signing for those who request it, or even maintain a repository of malware hashes (sort of antivirus), but making mandatory approval of addons is not something I'd like to see. - avih ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Layer Construction for Off Main Thread canvas
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 with the compositor, Compositable classes can be used by either the PLayerTransaction or the PImageBridge protocol. The logic to attach a Compositable using PImageBridge to a Layer using PLayerTransaction is rather simple (look at ImageClientBridge and ImageContainer) and mostly implemented in the CompositableClient/Host abstraction so you don't have to redo most of it. As Nick said you could have on the main thread a dummy CanvasClient analogous to ImageClientBridge which just forward an asyncID which is the ID used to connect the layer and the compositable on the compositor side, and on the ImageBridge thread you would have the usual CanvasClient. Then you'd need the equivalent of ImageContainer that would interface with the WebGLContext and forward frames to the ImageClient on the ImageBridge thread. This is the way we do with async video, which works well. This email is probably a bit confusing if you haven't looked at the Compositable stuff yet, so don't hesitate to ping me and ask questions about the compositor's IPC stuff and async updates. Cheers, Nical On Thu, Oct 31, 2013 at 7:03 AM, Kyle Huey m...@kylehuey.com wrote: On Thu, Oct 31, 2013 at 12:36 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Oct 31, 2013 at 5:28 PM, Kyle Huey m...@kylehuey.com wrote: One thing that's come up that we're not quite how to deal with for OMTcanvas is how to modify GetCanvasLayer. Our problem here is that the context here lives on the worker thread, and presumably we need to construct the layer on the main thread, but creating that layer requires data that also lives on the worker thread. We obviously can't block the main thread on a synchronous call to the worker, and we can't just lock around the values because that will break run to completion semantics on the worker (e.g. if the worker never yields, changes in the canvas size shouldn't take effect). I think the right thing to do is probably to ship the values from the worker to the main thread asynchronously as they are updated on the worker (once the worker yields/etc) and create the layer using those values. How often do we create layers? It would be a shame if rendering straight from the worker to the compositor were blocked by the main thread due to layer creation. Anything else we should be thinking about here? What values do you need from the worker in order to create the layer? Well, at the very least we need the dimensions of the canvas buffer. We need to know if the context is lost too, but that can already happen anytime so that's not too bad. The dimensions live on the worker thread (which can update them) so we need to either lock and read them from the main thread or maintain a separate copy of the dimensions on the main thread and post messages to update them. If we do the first then it's possible for the dimensions the compositor sees to be newer than the last data we pushed to it. If we do the latter then the opposite is possible. Does the compositor care if the layer size and the data we push to it are not in sync? The CanvasLayer also wants the GLContext to do stuff with it. Not sure what we're going to do with that ... It seems to me that we should be able to create a CanvasLayer on the main thread that is sized to the canvas element. Then from the CanvasLayer we get some kind of thread-safe object (analogous to the ImageContainer of an ImageLayer) which can be handed to the worker in the WorkerCanvas. This object would support being one end of the surface stream for WebGL. You would feed a series of surfaces into it which could have different sizes and the compositor will size them to the layer. That sounds reasonable ... it seems like just getting everything set up is the hard part. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A static analyzer found 3 potential security bugs in our code
Le 13-10-30 17:55, Florian Bender a écrit : Shouldn't this be posted to m.d.security? As far as I understood, m.d.security was more targeted at implementing security standards, not security bugs corrections. But I may be wrong. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A static analyzer found 3 potential security bugs in our code
Le 13-10-31 01:12, Jesse Ruderman a écrit : The three bug reports: https://bugzilla.mozilla.org/show_bug.cgi?id=823336 https://bugzilla.mozilla.org/show_bug.cgi?id=823338 https://bugzilla.mozilla.org/show_bug.cgi?id=826201 Short and efficient answer. Thanks Jesse! Do we still run this (and maybe other) tools to check our code periodically? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load
I think it makes a lot of sense to test the spread. +1 - Original Message - From: Armen Zambrano G. arme...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Tue, 29 Oct 2013 13:31:33 -0700 (PDT) Subject: Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load Hello all, I would like to re-visit this. I would like to look into stop running tests and talos for 10.7 and re-purpose those machines as 10.6 machines. * We have many more users on 10.6 than on 10.7. * No new updates have been given to 10.6 since July 2011 [1] * No new updates have been given to 10.7 since October, 2012 [2] This will improve our current Mac OSX testing wait times. On another note, 10.9 has come out and I already started seeing a decent dip on 10.8 users (since it is a free update). On another note, I would like to consider stop running jobs on 10.8 and only run them on 10.9 once we have the infrastructure up and running. cheers, Armen [1] https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard#Release_history [2] https://en.wikipedia.org/wiki/Mac_OS_X_Lion#Release_history On 2013-04-25 1:30 PM, Armen Zambrano G. wrote: (please follow up through mozilla.dev.planning) Hello all, I have recently been looking into our Mac OS X test wait times which have been bad for many months and progressively getting worst. Less than 80% of test jobs on OS X 10.6 and 10.7 are able to start within 15 minutes of being requested. This slows down getting tests results for OS X and makes tree closures longer if we have Mac OS X test back logs. Unfortunately, we can't buy any more revision 4 Mac minis (they're not sold anymore) as Apple discontinues old hardware as new ones comes out. In order to improve the turnaround time for Mac testing, we have to look into reducing our test load in one of these two OSes (both of them run on revision 4 minis). We have over a third of our OS X users running 10.6. Eventually, down the road, we could drop 10.6 but we still have a significant amount of our users there; even though Mac stopped serving them major updates since July 2011 [1]. Our current Mac OS X distribution looks like this: * 10.6 - 43% * 10.7 - 30% * 10.8 - 27% OS X 10.8 is the only version that is growing. In order to improve our wait times, I propose that we stop testing on tbpl per-checkin [2] on OS X 10.7 and re-purpose the 10.7 machines as 10.6 to increase our capacity. Please let us know if this plan is unacceptable and needs further discussion. best regards, Armen Zambrano - Mozilla's Release Engineering ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Supporting the Windows Certificate Store
On Wednesday, January 9, 2013 11:17:12 AM UTC-6, joshu...@gmail.com wrote: I know that there are probably well thought out reasons that this isn't a features already...BUT! Lot's of US Government users can't use Firefox because it doesn't use the Windows certificate store. Would anyone be totally opposed to adding this feature and having it enabled via group policy? That would allow some IT shops to roll it out with their preferred smart card middleware...like ActivClient. Thoughts? I'm in the same boat here working in a government environment and, though Firefox is my preferred browser, it is no longer usable for me. We put out our own certificates which are populated in the local cert store. That means that every browser will find them except Firefox and importing certs from the local store into Firefox's is too much for us to do on a large scale and even though Firefox usually asks for approval of an unknown cert when going to a page there have been times where it doesn't and I had to uninstall and reinstall the browser to get it to work. Using CACs is another issue though I was able to find a pluggin created by DISA at http://www.forge.mil/Resources-Firefox.html that allows Firefox to read them. There really should be a setting for Firefox to use the local store as an option or Firefox will rapidly fall into the realm of obsolescence when it comes to government and enterprise environments. In the mean time I am obligated to use Chrome. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla development bootcamp
I'm thinking all new contributors (volunteer or paid) and presented online as a series of videos (where applicable) with accompanying documentation. On Wed 30 Oct 2013 04:14:17 PM EDT, Josh Matthews wrote: Who is the audience? Where will this information be presented? On 10/30/2013 02:58 PM, Andrew Overholt wrote: I'm planning to coordinate development material for new contributors and I'd like your input on what should be included: https://etherpad.mozilla.org/mozbootcamp Thanks! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Sheriffs] Closure of trunk trees - owners for bugs needed
Since the concern has already been raised on IRC a few times about the likelihood of bustage pileups once the tree re-opens, I would also like to also throw out a quick reminder that Try wait times are probably the lowest they will ever be during a regular week because of this closure, so *please* do make sure any patches you're waiting to push have a green run first. Feel free to ping a sheriff in #developers if you're not sure about one of the results you're seeing. Thanks! -Ryan - Original Message - From: Carsten Book cb...@mozilla.com To: Ed Morley emor...@mozilla.com Cc: Sheriffs sheri...@mozilla.org, dev.platform dev-platform@lists.mozilla.org, dev.tree-management dev-tree-managem...@lists.mozilla.org Sent: Thursday, October 31, 2013 3:50:18 AM Subject: Re: [Sheriffs] Closure of trunk trees - owners for bugs needed Hi, good morning. Since the Trees are still closed here is a update as of 0:45am Pacific Time * https://bugzilla.mozilla.org/show_bug.cgi?id=932898 has an owner now * https://bugzilla.mozilla.org/show_bug.cgi?id=932880 Patch landed on inbound and tests are running. Cheers, - Tomcat - Original Message - From: Ed Morley emor...@mozilla.com To: Sheriffs sheri...@mozilla.org, dev.tree-management dev-tree-managem...@lists.mozilla.org, dev.platform dev-platform@lists.mozilla.org Sent: Wednesday, October 30, 2013 7:04:45 PM Subject: [Sheriffs] Closure of trunk trees - owners for bugs needed Hi all! Trunk trees are currently closed [1] - the requirements for reopening are: https://bugzilla.mozilla.org/show_bug.cgi?id=932781#c11 tl;dr we need owners for these bugs: * https://bugzilla.mozilla.org/show_bug.cgi?id=932898 * https://bugzilla.mozilla.org/show_bug.cgi?id=932880 Please can anyone who has any spare cycles take a look! :-) Best wishes, Ed [1] Apart from b2g-inbound, since that doesn't run Windows 7 tests, which are the ones that are being the most problematic. On 30 October 2013 14:09:47, Ed Morley wrote: I've broken the tree closing issues out into https://bugzilla.mozilla.org/show_bug.cgi?id=932781 and pasted the relevant parts of the IRC conversations from last night, because the OOMs are not constrained to that one existing bug it's good to get the IRC chat saved somewhere visible (I've only just managed to piece together what has been tried so far and where we're at). khuey is kindly looking at this some more once he's gotten sorted :-) Ed ___ Sheriffs mailing list sheri...@mozilla.org https://mail.mozilla.org/listinfo/sheriffs ___ Sheriffs mailing list sheri...@mozilla.org https://mail.mozilla.org/listinfo/sheriffs ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving Mac OS X 10.6 test wait times by reducing 10.7 load
On 10/29/2013 4:31 PM, Armen Zambrano G. wrote: In order to improve our wait times, I propose that we stop testing on tbpl per-checkin [2] on OS X 10.7 and re-purpose the 10.7 machines as 10.6 to increase our capacity. Please let us know if this plan is unacceptable and needs further discussion. best regards, Armen Zambrano - Mozilla's Release Engineering +1 to repurposing all rev4s as 10.6 slaves and all rev5s as 10.9! I guess the only question is how many people are stuck on 10.7 (my understanding is that some 10.7-supporting hardware configurations aren't supported on 10.9) and is that population large enough that we explicitly need to test for them? My offhand recollection is that the main discrepancies between the different OSX versions we see in our test infrastructure largely have to do with what hardware they're running on and whether OMTC is enabled or not. So IMO, 10.6 on rev4 w/o OMTC and 10.9 on rev5 w/ OMTC is probably representative enough that we aren't likely to miss any major regressions. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Style guidance on declaring foreign namespace return types/args/members in classes
On Fri, Nov 1, 2013 at 6:27 AM, Jonathan Watt jw...@jwatt.org wrote:
The style guide doesn't seem to address this:
When I have, say, a class in the global namespace called nsSVGUtils, what
is preferred:
class nsSVGUtils
{
public:
// blah blah
static mozilla::gfx::FillRule GetFillRule(mozilla::dom::**Element*
aElement);
// blah blah
};
or:
class nsSVGUtils
{
typedef mozilla::gfx::FillRule FillRule;
typedef mozilla::dom::Element Element;
public:
// blah blah
static FillRule GetFillRule(Element* aElement);
// blah blah
};
Or is either fine?
I strongly prefer the latter. It makes the code a lot more readable.
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt 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 *
*
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Style guidance on declaring foreign namespace return types/args/members in classes
Can we agree on using the using directive instead of typedefs when it comes to
namespaces? I think it's less likely to lead to confusing compile errors than
typedefs.
class nsSVGUtils
{
using mozilla::gfx::FillRule;
using mozilla::dom::Element;
public:
static FillRule GetFillRule(Element* aElement);
};
Thanks,
Monica
- Original Message -
On Fri, Nov 1, 2013 at 6:27 AM, Jonathan Watt jw...@jwatt.org wrote:
The style guide doesn't seem to address this:
When I have, say, a class in the global namespace called nsSVGUtils, what
is preferred:
class nsSVGUtils
{
public:
// blah blah
static mozilla::gfx::FillRule GetFillRule(mozilla::dom::**Element*
aElement);
// blah blah
};
or:
class nsSVGUtils
{
typedef mozilla::gfx::FillRule FillRule;
typedef mozilla::dom::Element Element;
public:
// blah blah
static FillRule GetFillRule(Element* aElement);
// blah blah
};
Or is either fine?
I strongly prefer the latter. It makes the code a lot more readable.
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt 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 *
*
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Style guidance on declaring foreign namespace return types/args/members in classes
On 10/31/13 3:05 PM, Monica Chew wrote:
Can we agree on using the using directive instead of typedefs when it comes to
namespaces? I think it's less likely to lead to confusing compile errors than
typedefs.
class nsSVGUtils
{
using mozilla::gfx::FillRule;
I believe this is not valid C++, sadly. g++ gives me:
error: using-declaration for non-member at class scope
whereas clang++ gives me:
error: using declaration in class refers into 'mozilla::gfx::', which
is not a class
Yes, that's pretty sucky. But as a result the typedef option is the
only option available here. :(
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Layer Construction for Off Main Thread canvas
On Thu, Oct 31, 2013 at 11:19 PM, Nicolas Silva nical.si...@gmail.comwrote: 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 with the compositor, Compositable classes can be used by either the PLayerTransaction or the PImageBridge protocol. The logic to attach a Compositable using PImageBridge to a Layer using PLayerTransaction is rather simple (look at ImageClientBridge and ImageContainer) and mostly implemented in the CompositableClient/Host abstraction so you don't have to redo most of it. As Nick said you could have on the main thread a dummy CanvasClient analogous to ImageClientBridge which just forward an asyncID which is the ID used to connect the layer and the compositable on the compositor side, and on the ImageBridge thread you would have the usual CanvasClient. Then you'd need the equivalent of ImageContainer that would interface with the WebGLContext and forward frames to the ImageClient on the ImageBridge thread. This last point is very important. It's very important that CanvasClient and ImageBridge and stuff like that not exposed outside the layers system. I think someone from gfx really needs to help with this part. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt 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 * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Style guidance on declaring foreign namespace return types/args/members in classes
Ugh, you're right :( I had originally tested in a class-less function. Within
class declarations using is only good for things in the base class.
http://en.cppreference.com/w/cpp/language/using_declaration
- Original Message -
On Fri, Nov 1, 2013 at 9:03 AM, Monica Chew m...@mozilla.com wrote:
This compiles using g++ for me.
namespace foo {
namespace bar {
class baz;
}
}
using foo::bar::baz;
class nsSVGUtils
{
public:
static baz GetFillRule(baz* aElement);
};
int main(void) {
return 0;
}
If we put that in nsSVGUtils.h, then that using directive brings baz
into the global scope for every translation unit that needs to #include
nsSVGUtils.h, which is no good. Putting a typedef in the class makes baz
available only within nsSVGUtils, which is what we want.
C++ just sucks here :-(.
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt 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 *
*
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Layer Construction for Off Main Thread canvas
I have no idea about construction and resizing, but webgl's frame flinging (and by extension skia-gl's) should Just Work already. WebGL content blithely calls SurfaceStream::SwapProducer, and somewhere in Layers/TextureClient/Host code there's a call to SurfaceStream::SwapConsumer. The only thing WebGL needs moved between the client and host size of things is the SurfaceStream pointer. -Jeff - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Nicolas Silva nical.si...@gmail.com Cc: Kyle Huey m...@kylehuey.com, Morris Tseng mts...@mozilla.com, Jeff Gilbert jgilb...@mozilla.com, Benoit Jacob bja...@mozilla.com, Milan Sreckovic msrecko...@mozilla.com, Matt Woodrow mwood...@mozilla.com, Nicholas Cameron n...@mozilla.com, dev-platform dev-platform@lists.mozilla.org Sent: Thursday, October 31, 2013 12:54:42 PM Subject: Re: Layer Construction for Off Main Thread canvas On Thu, Oct 31, 2013 at 11:19 PM, Nicolas Silva nical.si...@gmail.comwrote: 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 with the compositor, Compositable classes can be used by either the PLayerTransaction or the PImageBridge protocol. The logic to attach a Compositable using PImageBridge to a Layer using PLayerTransaction is rather simple (look at ImageClientBridge and ImageContainer) and mostly implemented in the CompositableClient/Host abstraction so you don't have to redo most of it. As Nick said you could have on the main thread a dummy CanvasClient analogous to ImageClientBridge which just forward an asyncID which is the ID used to connect the layer and the compositable on the compositor side, and on the ImageBridge thread you would have the usual CanvasClient. Then you'd need the equivalent of ImageContainer that would interface with the WebGLContext and forward frames to the ImageClient on the ImageBridge thread. This last point is very important. It's very important that CanvasClient and ImageBridge and stuff like that not exposed outside the layers system. I think someone from gfx really needs to help with this part. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt 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 * * ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Trouble building trunk as debug ASAN on OS X
Started happening recently, though I'm not sure if it's my system or something changed in our code. Anyone else able to build ASAN debug on OS X? I'm using clang. This is what I get: 8:23.40 1. /Users/msreckovic/Repos/mozilla-asan/widget/cocoa/nsChildView.mm:6175:1: current parser token 'void' 8:23.40 2. /Users/msreckovic/Repos/mozilla-asan/widget/cocoa/nsChildView.mm:2738:15: LLVM IR generation of declaration 'globalDragPboard' 8:23.81 IonFrames-x86-shared.o 8:23.86 TestWebGLElementArrayCache.o 8:24.37 clang: error: unable to execute command: Illegal instruction: 4 8:24.37 clang: error: clang frontend command failed due to signal (use -v to see invocation) 8:24.37 clang version 3.2 (trunk 163716) 8:24.37 Target: x86_64-apple-darwin12.4.0 8:24.37 Thread model: posix 8:24.37 clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. 8:24.50 Element.o 8:25.00 clang: note: diagnostic msg: 8:25.00 8:25.01 8:25.01 PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: 8:25.01 Preprocessed source(s) and associated run script(s) are located at: 8:25.01 clang: note: diagnostic msg: /var/folders/0y/9xx0_t1x54zc9qnf3rc_8z20gn/T/nsChildView-XPNcRM.mm 8:25.01 clang: note: diagnostic msg: /var/folders/0y/9xx0_t1x54zc9qnf3rc_8z20gn/T/nsChildView-XPNcRM.sh 8:25.01 clang: note: diagnostic msg: -- - Milan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Closure of trunk trees - owners for bugs needed
On Wed, Oct 30, 2013 at 11:04 AM, Ed Morley emor...@mozilla.com wrote: Hi all! Trunk trees are currently closed [1] - the requirements for reopening are: https://bugzilla.mozilla.org/show_bug.cgi?id=932781#c11 I have (slightly optimistically) started writing a post-mortem of this closure, analyzing what went wrong and why, and how we might avoid it in the future: https://etherpad.mozilla.org/mEB0H50ZjX It's only partially written, because I only have a partial understanding. In particular, the Mochi-2 failures and fixes are well described, but the Mochi-bc failures and fixes are less so. Andrew McCreight has already added some good details, and I ask everyone else who has been involved with diagnosing and fixing this situation to do likewise. Thanks. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Closure of trunk trees - owners for bugs needed
On Thu, Oct 31, 2013 at 6:52 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Remaining things I'm aware of: One more: lots of patches will need to be backported to Aurora and Beta. I've set the appropriate tracking flags on the bugs that I think need it, but please double-check ones you know about in case I've missed any. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Closure of trunk trees - owners for bugs needed
I have (slightly optimistically) started writing a post-mortem of this closure, analyzing what went wrong and why, and how we might avoid it in the future: https://etherpad.mozilla.org/mEB0H50ZjX FWIW, I added the following TL;DR to the document, which reflects my understanding of the situation. Win7 M2 and Mbc tests were OOMing frequently at shutdown because too many DOM windows were open. This was due to a combination of: (a) multiple badly written tests, (b) multiple social API leaks, (c) multiple devtool leaks. Bug 932898 will improve our shutdown leak detection. Bug 932900 will (if implemented) prevent some of these leaks(?). Is there anything else we can do to prevent this from happening again? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
