On Wed, Mar 21, 2012 at 8:29 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 20, 2012, at 12:00 PM, James Robinson wrote:
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many optimization
opportunities that are
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote:
Carrots and Sticks.
Aren't we missing an opportunity here? By giving web developers this easy
migration path, you're also giving up the opportunity to encourage them to
use a better API. Asynchronous APIs are harder
On 4/16/2012 11:07 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:29 PM, Maciej Stachowiakm...@apple.com wrote:
On Mar 20, 2012, at 12:00 PM, James Robinson wrote:
If we are adding new APIs for manipulating the backing directly, can we
make them asynchronous? This would allow for many
On 4/16/2012 11:17 AM, Oliver Hunt wrote:
Anyway, the sensible approach to imagedata + hardware backed canvas is to
revert to a software backed canvas, as once someone has used imagedata once,
they're likely to do it again (and again, and again) so it is probably a win to
just do everything
On Mon, Apr 16, 2012 at 11:17 AM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote:
Carrots and Sticks.
Aren't we missing an opportunity here? By giving web developers this
easy
migration path, you're also giving up the
On Apr 16, 2012, at 11:38 AM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 11:17 AM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote:
Carrots and Sticks.
Aren't we missing an opportunity here? By giving web
On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote:
I don't understand why adding a runloop cycle to any read seems like
something that would introduce a much more noticable delay than a memcopy.
The use case is deferred rendering. Canvas drawing calls don't need to
complete
Could someone construct a demonstration of where the read back of the imagedata
takes longer than a runloop cycle?
You're asking for significant additional complexity for content authors, with a
regression in general case performance, it would be good to see if it's
possible to create an
Glenn summarizes my concerns exactly. Deferred rendering is indeed the
more precise issue.
On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote:
Could someone construct a demonstration of where the read back of the
imagedata takes longer than a runloop cycle?
I bet this
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal version
of window.confirm() or
On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote:
Glenn summarizes my concerns exactly. Deferred rendering is indeed the more
precise issue.
On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote:
Could someone construct a demonstration of where the read
On 16 Apr 2012 at 19:07, Darin Fisher da...@chromium.org wrote:
Aren't we missing an opportunity here? By giving web developers this easy
migration path, you're also giving up the opportunity to encourage them to
use a better API. Asynchronous APIs are harder to use, and that's why we
need
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote:
See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that
didn't exist. Note how we recently withdrew support for synchronous
ArrayBuffer access on XHR? We did this precisely to discourage use of
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote:
dialog will give a better user
On Mon, Apr 16, 2012 at 1:45 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote:
See synchronous XMLHttpRequest. I'm sure every browser vendor wishes
that
didn't exist. Note how we recently withdrew support for synchronous
On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote:
Con: Encourages poor HI design (since these stock dialogs should almost
never be used).
That being said, I find in-page UI less objectionable than a
On Apr 16, 2012, at 2:00 PM, Darin Fisher da...@chromium.org wrote:
I have learned that it is not commonly accepted that reading ImageData can be
slow. I had assumed otherwise.
Yes, it's possible to make reading image data slow, but i can make _anything_
slow. I could make postMessage slow
On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote:
On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote:
I don't understand why adding a runloop cycle to any read seems like
something that would introduce a much more noticable delay than a memcopy.
The use case is deferred
On Apr 16, 2012, at 1:52 PM, Darin Fisher wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote:
On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 7:54 PM,
On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote:
Glenn summarizes my concerns exactly. Deferred rendering is indeed the
more precise issue.
On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt
On Mon, Apr 16, 2012 at 2:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote:
On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote:
I don't understand why adding a runloop cycle to any read seems like
something that would
On Apr 16, 2012, at 2:34 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote:
Glenn summarizes my concerns exactly. Deferred rendering is indeed the
more
On Mon, Apr 16, 2012 at 2:18 PM, Oliver Hunt oli...@apple.com wrote:
Could someone construct a demonstration of where the read back of the
imagedata takes longer than a runloop cycle?
Runloop doesn't mean anything to me (nor to Google [1], nor to the HTML
specification). If you're talking
On Mon, Apr 16, 2012 at 2:57 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 2:34 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote:
On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote:
Glenn
On Mon, Apr 16, 2012 at 2:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com
wrote:
Con: Encourages poor HI design (since these stock dialogs should almost
Can you hide this behind adoptNode just as we did for magic iframe? The
nice thing about adoptNode is that the browser gets told both the source and
destination parent nodes. This way there is never a disconnected state.
So long as we unload when moving between documents, we should be pretty
FWIW, IE used to not reload iframes when they were moved around in the
tree. They changed this behavior in IE9 so maybe there was some compat
issues?
erik
On Mon, Apr 16, 2012 at 16:51, Darin Fisher da...@chromium.org wrote:
Can you hide this behind adoptNode just as we did for magic
On Mon, 5 Dec 2011, Adam Barth wrote:
I wrote some somewhat goofy text in the CSP spec trying to integrate the
sandbox directive with HTML's iframe sandbox machinery. Hixie and I
chatted in #whatwg about how best to do the integration. I think Hixie
is going to refactor the machinery in
28 matches
Mail list logo
