On Friday, October 11, 2013 12:53:27 PM UTC+2, Bobby Holley wrote:
On Fri, Oct 11, 2013 at 10:24 AM, Matthew Gertner
What I can't seem to figure out is how to make it so that content can add
new properties to a COW (as opposed to modifying existing properties).
Totally different question,
One of the shumway goals has been to run most or all of shumway in a
worker, so that it can run in parallel with a web page the same way
Flash currently does. This will significantly help solve jank associated
with shumway loading.
However, we still need to support the Flash externalInterface
How common are the blocking API calls? Can we somehow predict whether
the SWF will need that, and optionally use a worker/non-worker context
based on that?
We can do whatever we like in Gecko, but I'd imagine that any proposal
to allow blocking on a worker will meet significant resistance in the
On 10/14/2013 12:06 PM, Bobby Holley wrote:
How common are the blocking API calls?
Expect them to be very common or almost universal for real Flash. Much
less common for simple display ads.
Can we somehow predict whether
the SWF will need that, and optionally use a worker/non-worker context
- Original Message -
How common are the blocking API calls? Can we somehow predict whether
the SWF will need that, and optionally use a worker/non-worker context
based on that?
Fairly common: many SWFs use ExternalInterface at least once, and even more use
BitmapData#draw, which
Didn't see this before now, sorry.
On Mon, Oct 14, 2013 at 6:15 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:
On 10/14/2013 12:06 PM, Bobby Holley wrote:
How common are the blocking API calls?
Expect them to be very common or almost universal for real Flash. Much
less common for simple
On Mon, Oct 14, 2013 at 6:21 PM, Till Schneidereit t...@mozilla.com wrote:
Nobody's proposing to expose any of this to web content. The question is
whether we want to fully expose it as an official capability of Gecko, to be
used by other parts of the browser and maybe even addons, or if we
On Mon, Oct 14, 2013 at 6:30 PM, Bobby Holley bobbyhol...@gmail.com wrote:
On Mon, Oct 14, 2013 at 6:21 PM, Till Schneidereit t...@mozilla.com wrote:
Nobody's proposing to expose any of this to web content. The question is
whether we want to fully expose it as an official capability of Gecko,
On Mon, Oct 14, 2013 at 11:03 AM, Benjamin Smedberg
benja...@smedbergs.uswrote:
Having this blocking interface will also support blocking shumway on
graphics rendering; there are a fair number of SWF files that use an API to
get a synchronous bitmap of their stage, which requires a blocking
On 10/14/2013 4:12 PM, Robert O'Callahan wrote:
On Mon, Oct 14, 2013 at 11:03 AM, Benjamin Smedberg
benja...@smedbergs.us mailto:benja...@smedbergs.us wrote:
Having this blocking interface will also support blocking shumway
on graphics rendering; there are a fair number of SWF files
On Mon, Oct 14, 2013 at 10:16 PM, Benjamin Smedberg
benja...@smedbergs.us wrote:
On 10/14/2013 4:12 PM, Robert O'Callahan wrote:
On Mon, Oct 14, 2013 at 11:03 AM, Benjamin Smedberg benja...@smedbergs.us
mailto:benja...@smedbergs.us wrote:
Having this blocking interface will also support
On Mon, Oct 14, 2013 at 4:16 PM, Benjamin Smedberg benja...@smedbergs.uswrote:
Is canvas-on-a-worker a short-term project?
WebGL is at least.
Also from reading the whatwg discussion, I thought you had proposed .toBlob
but not .toDataURI specifically so that the bitmap was not synchronously
On Mon, Oct 14, 2013 at 4:29 PM, Till Schneidereit
t...@tillschneidereit.net wrote:
From talking to Kyle, it sounds like getting WebGL into workers is
much closer than getting all of Context2D, too. Specifically, we need
text rendering to work, because we have to be able to render device
On Mon, Oct 14, 2013 at 11:31 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Mon, Oct 14, 2013 at 4:29 PM, Till Schneidereit
t...@tillschneidereit.net wrote:
From talking to Kyle, it sounds like getting WebGL into workers is
much closer than getting all of Context2D, too. Specifically,
Now that everyone's back from Summit, it's time to MemShrink...
The next MemShrink meeting will be brought to you by bug 771765
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we
15 matches
Mail list logo
