On Wed, Dec 19, 2012 at 5:39 PM, Rik Cabanier caban...@gmail.com wrote:
On Tue, Dec 18, 2012 at 1:14 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
It seems to me a synchronous constructor that creates an ImageBitmap for
a subimage of another ImageBitmap (but not other kind of source!)
On Wed, Dec 19, 2012 at 1:29 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, Dec 19, 2012 at 5:39 PM, Rik Cabanier caban...@gmail.com wrote:
On Tue, Dec 18, 2012 at 1:14 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
It seems to me a synchronous constructor that creates an
On Thu, Dec 20, 2012 at 7:33 AM, Rik Cabanier caban...@gmail.com wrote:
Would it also handled HD backing stores automatically, like drawImage
does?
I think so.
Rob
--
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials
Thanks Ian.
http://html5.org/tools/web-apps-tracker?from=7588to=7589
On Tue, Dec 18, 2012 at 1:04 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Dec 18, 2012 at 6:57 PM, Rik Cabanier caban...@gmail.com wrote:
Does it matter that this solution is in the image world and not 2d
Is it possible to expose the width/height of an ImageBitmap, or even
expose all the rectangle coordinates? Exposing width/height would be
nice for parity with Image and Canvas when writing functions that
accept any drawable image source.
Thanks for the prompt action here, this looks like a
Sorry, upon reading over the ImageBitmap part of the spec again I'm
confused: Why is constructing an ImageBitmap asynchronous? I thought
any decoding isn't supposed to happen until drawImage, so I don't
really understand why this operation involves a callback and a delay.
Making ImageBitmap
On Tue, Dec 18, 2012 at 10:17 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Sorry, upon reading over the ImageBitmap part of the spec again I'm
confused: Why is constructing an ImageBitmap asynchronous? I thought
any decoding isn't supposed to happen until drawImage, so I don't
really understand
How do you wait synchronously for a callback from inside
requestAnimationFrame? I'm not aware of a way to do this in the spec.
Furthermore, wouldn't that mean returning once to the event loop for
each individual drawImage call you wish to make using a source
rectangle - so for a single scene
On Tue, Dec 18, 2012 at 11:03 AM, Kevin Gadd kevin.g...@gmail.com wrote:
How do you wait synchronously for a callback from inside
requestAnimationFrame?
If you are inside a rAF callback, you exit the callback, and resume drawing
in the createBitmapImage callback.
I'm not aware of a way to
Each time you wait for that callback, won't any pending drawing
operations to your canvas get flushed, resulting in the scene slowly
rendering onscreen?
Another great reason to batch the calls, as described above.
Another solution is to use an offscreen canvas.
-kg
On Tue, Dec
On Wed, Dec 19, 2012 at 4:17 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Sorry, upon reading over the ImageBitmap part of the spec again I'm
confused: Why is constructing an ImageBitmap asynchronous? I thought
any decoding isn't supposed to happen until drawImage, so I don't
really understand
On Tue, Dec 18, 2012 at 1:14 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, Dec 19, 2012 at 4:17 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Sorry, upon reading over the ImageBitmap part of the spec again I'm
confused: Why is constructing an ImageBitmap asynchronous? I thought
any
On Sun, Dec 16, 2012 at 11:52 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Dec 12, 2012 at 10:24 AM, Justin Novosad ju...@chromium.orgwrote:
On Wed, Dec 12, 2012 at 12:39 PM, Rik Cabanier caban...@gmail.comwrote:
What would be the next step? Should we define a new version of
A simple way to create an Image that represents a subregion of another
Image or Canvas would be a nice solution here, since for
implementations that need a temporary image anyway this lets them
ensure it's only created once, and it lets you avoid the costs
associated with temporary canvases. A few
On Mon, Dec 17, 2012 at 10:33 AM, Kevin Gadd kevin.g...@gmail.com wrote:
A simple way to create an Image that represents a subregion of another
Image or Canvas would be a nice solution here, since for
implementations that need a temporary image anyway this lets them
ensure it's only created
On Mon, Dec 17, 2012 at 7:23 AM, Justin Novosad ju...@chromium.org wrote:
On Sun, Dec 16, 2012 at 11:52 PM, Rik Cabanier caban...@gmail.com wrote:
On Wed, Dec 12, 2012 at 10:24 AM, Justin Novosad ju...@chromium.orgwrote:
On Wed, Dec 12, 2012 at 12:39 PM, Rik Cabanier
Isn't this the same as what Ian suggested: copy it to a temporary canvas
and use the temporary canvas scales.
It seems that you can optimize that case too.
Hmm... It would one of those optimizations that only works if you perform
the secret handshake just right.
If I understand correctly, the
On Mon, Dec 17, 2012 at 11:49 AM, Justin Novosad ju...@chromium.org wrote:
Isn't this the same as what Ian suggested: copy it to a temporary canvas
and use the temporary canvas scales.
It seems that you can optimize that case too.
Hmm... It would one of those optimizations that only works
On Mon, Dec 17, 2012 at 1:23 PM, Rik Cabanier caban...@gmail.com wrote:
On Mon, Dec 17, 2012 at 11:49 AM, Justin Novosad ju...@chromium.org wrote:
Isn't this the same as what Ian suggested: copy it to a temporary canvas
and use the temporary canvas scales.
It seems that you can optimize
On Tue, Dec 18, 2012 at 4:23 AM, Justin Novosad ju...@chromium.org wrote:
This gives me another
idea: we could just have a new Image constructor that creates a new image
element that is a subregion of another:
var mySprite = new Image(spriteMap, x, y, w, h);
This can be implemented in a
On Tue, Dec 18, 2012 at 6:57 PM, Rik Cabanier caban...@gmail.com wrote:
Does it matter that this solution is in the image world and not 2d canvas?
It seems that this will have a bigger impact on the browser's codebase
since it spans images and canvas.
I think that's a good thing --- it's
On Wed, Dec 12, 2012 at 10:24 AM, Justin Novosad ju...@chromium.org wrote:
On Wed, Dec 12, 2012 at 12:39 PM, Rik Cabanier caban...@gmail.com wrote:
What would be the next step? Should we define a new version of drawImage
with the extra parameter?
That is one option, but I think a
On Tue, Dec 11, 2012 at 7:56 AM, Justin Novosad ju...@chromium.org wrote:
On Mon, Dec 10, 2012 at 6:53 PM, Rik Cabanier caban...@gmail.com wrote:
I assume this would only be for the 9 argument version of drawImage?
Yeah, the all dressed version.
FWIW
I was curious why this bug
On Wed, 12 Dec 2012, Rik Cabanier wrote:
What would be the next step? Should we define a new version of drawImage
with the extra parameter?
At the WHATWG, the process, insofar as there is one, is that the spec's
editor (in this case me) goes through the e-mails on a topic and edits the
spec
On Wed, Dec 12, 2012 at 10:16 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 12 Dec 2012, Rik Cabanier wrote:
What would be the next step? Should we define a new version of drawImage
with the extra parameter?
At the WHATWG, the process, insofar as there is one, is that the spec's
editor
On Wed, Dec 12, 2012 at 12:39 PM, Rik Cabanier caban...@gmail.com wrote:
What would be the next step? Should we define a new version of drawImage
with the extra parameter?
That is one option, but I think a context attribute (like
imageSmoothingEnabled) is also worth considering.
Perhaps
I agree. What I meant to say that the spec should specify that resampling
behavior is undefined with the existing API.
It would of course be best if WK would fix their code so it follows the
current spec description and instructs developers to use the new parameter.
Yep. That's how I see
On Mon, Dec 10, 2012 at 6:53 PM, Rik Cabanier caban...@gmail.com wrote:
I assume this would only be for the 9 argument version of drawImage?
Yeah, the all dressed version.
FWIW
I was curious why this bug doesn't show up in WebKit so I looked at the
implementation.
They actually catch
On Mon, 20 Aug 2012, Kevin Gadd wrote:
Hi, I've been digging into an inconsistency between various browsers'
Canvas implementations and I think the spec might be allowing
undesirable behavior here.
The current version of the spec says
(Sorry if you get this twice. For some reason my first reply was
bounced by the listserv?)
On Mon, Dec 10, 2012 at 10:24 AM, Ian Hickson i...@hixie.ch wrote:
There's two ways to do scaled sprites with drawImage(): have a border of
transparent black around each sprite, or copy the data out of
On Mon, Dec 10, 2012 at 1:24 PM, Ian Hickson i...@hixie.ch wrote:
The reason to prefer the current behaviour is if you want to just update a
small part of an image. For example, if you draw a bit photo, then draw
text over it, then want to remove the text by just drawing the photo over
where
On Mon, Dec 10, 2012 at 11:03 AM, Justin Novosad ju...@chromium.org wrote:
On Mon, Dec 10, 2012 at 1:24 PM, Ian Hickson i...@hixie.ch wrote:
The reason to prefer the current behaviour is if you want to just update
a
small part of an image. For example, if you draw a bit photo, then draw
I can't speak for the most common approach in HTML5 games, but using a
temporary surface for drawing sprites is definitely not a common
approach in non-canvas games. I've never seen it proposed before this
thread for canvas dev, either, but I'm not an expert there. This is at
least an area where
On Mon, Dec 10, 2012 at 4:04 PM, Rik Cabanier caban...@gmail.com wrote:
As Ian said, copying the sprite image to a non-scaled canvas first (which
most games probably do anyway) works around the issue.
There is no need for padding in that case.
Yes, I am sure a lot of games do it already to
On Mon, Dec 10, 2012 at 1:18 PM, Justin Novosad ju...@chromium.org wrote:
On Mon, Dec 10, 2012 at 4:04 PM, Rik Cabanier caban...@gmail.com wrote:
As Ian said, copying the sprite image to a non-scaled canvas first (which
most games probably do anyway) works around the issue.
There is no
This is pretty tricky to get right -- there's just a general graphics
problem in this case. There are valid use cases for both sampling outside
and not sampling outside the source rectangle, as well as implementation
issues for being able to do source rectangle clamping. For example, should
you
On 2012-09-10, at 3:43 PM, Vladimir Vukicevic wrote:
This is pretty tricky to get right -- there's just a general graphics
problem in this case. There are valid use cases for both sampling outside
and not sampling outside the source rectangle, as well as implementation
issues for being able
On Mon, Sep 10, 2012 at 4:49 PM, Jeff Muizelaar jmuizel...@mozilla.comwrote:
On 2012-09-10, at 3:43 PM, Vladimir Vukicevic wrote:
FWIW, there are also negative performance implications to clamping samples
to the source rect. Many graphics APIs do not support this kind sampling,
and
On 2012-09-10, at 5:28 PM, Justin Novosad wrote:
On Mon, Sep 10, 2012 at 4:49 PM, Jeff Muizelaar jmuizel...@mozilla.com
wrote:
On 2012-09-10, at 3:43 PM, Vladimir Vukicevic wrote:
FWIW, there are also negative performance implications to clamping samples to
the source rect. Many
Hi, I've been digging into an inconsistency between various browsers'
Canvas implementations and I think the spec might be allowing
undesirable behavior here.
The current version of the spec says
Hi Kevin,
The same artifact use to be present in Chrome not that long ago. When we
fixed it, we chose to interpret original image data as meaning the part
of the image data that is within the bounds of the of the source rectangle.
Also, it makes more sense to do it that way. I agree that the spec
Hi Kevin,
can you log a bug on this? https://www.w3.org/Bugs/Public/enter_bug.cgi
once it's in the system, we can fix the wording in the spec.
Rik
On Mon, Aug 20, 2012 at 6:38 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Hi, I've been digging into an inconsistency between various browsers'
On Mon, 20 Aug 2012, Rik Cabanier wrote:
can you log a bug on this?
https://www.w3.org/Bugs/Public/enter_bug.cgi once it's in the system, we
can fix the wording in the spec.
No need to file a bug; any e-mail sent to this list automatically ends up
on the list of issues to fix and will
43 matches
Mail list logo
