Re: [whatwg] Question on Limits in Adaption Agency Algorithm
On Sat, Dec 8, 2012 at 11:05 PM, Ian Hickson i...@hixie.ch wrote: the order between abc and xyz is reversed in the tree. Does anyone have any preference for how this is fixed? Does it need to be fixed? That is, is it breaking real sites? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Question on Limits in Adaption Agency Algorithm
On Wed, 12 Dec 2012, Henri Sivonen wrote: On Sat, Dec 8, 2012 at 11:05 PM, Ian Hickson i...@hixie.ch wrote: the order between abc and xyz is reversed in the tree. Does anyone have any preference for how this is fixed? Does it need to be fixed? That is, is it breaking real sites? It reverses the order of text nodes. That's ridiculously unintuitive. Yes, I think it needs solving, even if it isn't hit by any sites. (If it's hit by sites, it seems likely that they are breaking because of it. If it isn't, then we can safely change it regardless.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
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 doesn't show up in WebKit so I looked at the implementation. They actually catch cases where there's scaling of a portion of an image and special case it by copying the non-scaled image to a temporary canvas first: // When the image is scaled using high-quality interpolation, we create a temporary CGImage // containing only the portion we want to display. We need to do this because high-quality // interpolation smoothes sharp edges, causing pixels from outside the source rect to bleed // into the destination rect. See rdar://problem/6112909. It would be nice to see why the Safari folks added this code since it makes them inconsistent with the spec. For the skia port of WebKit (used by Chrome) clamping to the source region is built into the blitter functions (sw rendering) and shaders (gpu rendering) so that color bleeding can be prevented without creating a temporary copy of the image. The reason it was implemented this way is that the bleeding was reported as a bug by game developers and the spec was not as clear then as it is today. We were getting more complaints about this issue back when there was color bleeding, which is the main reason why I have been arguing in favor of clamping to the bounds of the source rectangle. It seems more web developers are getting the results they expect from drawImage now that there is no color bleeding in Chrome, which is unfortunately not spec compliant behavior. What would be the next step? Should we define a new version of drawImage with the extra parameter? If so, we probably want the description of the existing drawImage call to change so it leaves the resampling issue undefined unless WebKit is OK with changing their current behavior.
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
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 based on the feedback and based on how much vendor buy-in an issue has. On this particular topic, I've only heard interest in implementing this from one vendor, Google, so adding support to the spec at this point is probably premature. If other vendors are interested in implementing something for this (a feature to make drawImage scale subsets with clamping at the source rectangle rather than the original image), I encourage them to indicate this on this thread. If so, we probably want the description of the existing drawImage call to change so it leaves the resampling issue undefined unless WebKit is OK with changing their current behavior. Leaving the spec undefined is not acceptable. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
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 (in this case me) goes through the e-mails on a topic and edits the spec based on the feedback and based on how much vendor buy-in an issue has. On this particular topic, I've only heard interest in implementing this from one vendor, Google, so adding support to the spec at this point is probably premature. If other vendors are interested in implementing something for this (a feature to make drawImage scale subsets with clamping at the source rectangle rather than the original image), I encourage them to indicate this on this thread. If so, we probably want the description of the existing drawImage call to change so it leaves the resampling issue undefined unless WebKit is OK with changing their current behavior. Leaving the spec undefined is not acceptable. :-) 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.
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
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 image smoothing could be an enum rather than boolean with an additional mode that prevents color bleeding. If so, we probably want the description of the existing drawImage call to change so it leaves the resampling issue undefined unless WebKit is OK with changing their current behavior. IMHO: Undifined behavior is a spec bug. If we have a problem with the spec, we fix the spec, we don't just each do our own thing.
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
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 it: we currently have a compliance bug in our implementation.
Re: [whatwg] Question on Limits in Adaption Agency Algorithm
On Wed, 12 Dec 2012, Ian Hickson wrote: On Wed, 12 Dec 2012, Henri Sivonen wrote: On Sat, Dec 8, 2012 at 11:05 PM, Ian Hickson i...@hixie.ch wrote: the order between abc and xyz is reversed in the tree. Does anyone have any preference for how this is fixed? Does it need to be fixed? That is, is it breaking real sites? It reverses the order of text nodes. That's ridiculously unintuitive. Yes, I think it needs solving, even if it isn't hit by any sites. (If it's hit by sites, it seems likely that they are breaking because of it. If it isn't, then we can safely change it regardless.) Although changing it does introduce the possibility of unforeseen regressions. Not that I have a strong opinion here, really.
