Re: [whatwg] getImageData/putImageData comments
On May 31, 2009, at 6:55 PM, Boris Zbarsky wrote: 3) It's not clear to me why imagedata actually exposes device pixels, nor is it clear to me how this is supposed to work if the same document is being rendered to multiple devices. Is a UA allowed to have a higher internal resolution for a canvas (in device pixels) and then sample when painting to the device? This might well be desirable if the UA expects the canvas to be scaled; it can well reduce scaling artifacts in that situation. It doesn't seem reasonable, to me, to expose such super-sampling via imageData; it's entirely an optimization detail. Worse yet, the current setup means that a script that tries createImageData, fill in the pixels, and then paint it to the canvas, needs to fill different numbers of pixels depending on the output device. I fully expect script authors to get this very very wrong, since it's such non-intuitive behavior. It would make more sense to just have the script work entirely in CSS pixels; if it wishes to create a higher-resolution image it can create a canvas with bigger dimensions (and scale its actual display via setting its width and height CSS properties). In some environments, a CSS pixel may be more than one device pixel. In this case, getImageData followed by putImageData will lose resolution. In other cases, a CSS pixel may be a non-integer number of device pixels. To see an example of a browser running in this environment, on Mac OS X launch Quartz Debug, open the User Interface Resolution window, and try setting the scale factor to 1.5 or 2.0. In this case in Safari, the CSS px unit will respect the scale factor, but the canvas backing store will still be in device pixels so users get the benefit of the higher resolution. (Currently Apple doesn't ship any systems that use a non-1.0 UI scale factor by default.) The current design makes it possible to write code that will do the right thing in a scaled UI. It also makes it easy to do the wrong thing and copy only a fraction of the area intended. The alternate design of using CSS pixels would make it impossible to get right, but the failure mode would just be to lose resolution. Regards, Maciej
Re: [whatwg] getImageData/putImageData comments
On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote: Here are a couple of relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html Then there was a discussion on #whatwg more recently. http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-263 So far it seems the data supports the hypothesis that authors expect getImageData to return 1 image pixel per CSS pixel and their scripts break when that's not true. That won't change until authors all have high-dpi screens. I'm not surprised. On the other hand, if we use CSS pixels, it won't be possible for authors to get it right, even if they do have high-dpi screens. It might be wise to have separate APIs (or a distinguishing parameter) to indicate whether you want scaled or true resolution. That way, unaware code gets a resolution loss, but aware code can do the right thing. I guess you suggested something like that in the IRC conversation you cited. Regards, Maciej
Re: [whatwg] getImageData/putImageData comments
On Mon, Jun 1, 2009 at 7:13 PM, Maciej Stachowiak m...@apple.com wrote: On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote: Here are a couple of relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html Then there was a discussion on #whatwg more recently. http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-263 So far it seems the data supports the hypothesis that authors expect getImageData to return 1 image pixel per CSS pixel and their scripts break when that's not true. That won't change until authors all have high-dpi screens. I'm not surprised. On the other hand, if we use CSS pixels, it won't be possible for authors to get it right, even if they do have high-dpi screens. It might be wise to have separate APIs (or a distinguishing parameter) to indicate whether you want scaled or true resolution. That way, unaware code gets a resolution loss, but aware code can do the right thing. I guess you suggested something like that in the IRC conversation you cited. Yes. Why don't we just redefine getImageData right now to have the behaviour authors are depending on, since we will likely be forced into that anyway? I'm not sure whether we should define the new API right now (getHighResolutionImageData?), or wait until CSS-to-device-pixel-ratios != 1 are common enough that authors are likely to use the new API correctly. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate.
On Sat, 30 May 2009 05:49:20 +0200, wha...@whatwg.org wrote:
Author: ianh
Date: 2009-05-29 20:49:18 -0700 (Fri, 29 May 2009)
New Revision: 3151
Modified:
index
source
Log:
[] (0) Try to make the magic margin collapsing rule more accurate.
Modified: source
===
--- source 2009-05-30 02:33:07 UTC (rev 3150)
+++ source 2009-05-30 03:49:18 UTC (rev 3151)
@@ -80436,9 +80436,10 @@
form { margin-bottom: 1em; }/pre
pWhen a codeDocument/code is in spanquirks mode/span,
- margins on spanHTML elements/span at the top or bottom of the
- initial containing block, or the top of bottom of codetd/code or
- codeth/code elements, are expected to be collapsed to zero./p
+ margins on spanHTML elements/span at the top or bottom of
+ spanthe body element/span, or the top of bottom of
+ codetd/code or codeth/code elements, are expected to be
+ collapsed to zero./p
h4Alignment/h4
Please change spanthe body element/span to codebody/code
elements.
--
Simon Pieters
Opera Software
Re: [whatwg] getImageData/putImageData comments
Maciej Stachowiak wrote: In some environments, a CSS pixel may be more than one device pixel. Yes, I'm well aware. In this case, getImageData followed by putImageData will lose resolution. Right. I did mention that in my reply to Oliver. It seems that there are two significantly different use cases for putImageData. One is that of doing getImageData on a canvas followed by some manipulation of the existing pixel data. In this case I agree that: The current design makes it possible to write code that will do the right thing in a scaled UI. It also makes it easy to do the wrong thing and copy only a fraction of the area intended. I'm not quite sure what I think of the tradeoffs here yet, and I need to go read through the old discussions, but I do appreciate the problems. The other use case is doing createImageData, followed by filling in the pixels, followed by putImageData. In this case, there is no quality loss of existing data involved, but the current design still makes it easy to do the wrong thing... In fact, it makes it much more difficult than it should be to do the right thing for a typical web developer. Perhaps the two use cases should use a different put API and incompatible imagedata objects and actually use different coordinate spaces? It'd be somewhat confusing, but the use cases for the two seem to me to be sufficiently different that it might be warranted... -Boris
Re: [whatwg] getImageData/putImageData comments
Boris Zbarsky wrote: The other use case is doing createImageData, followed by filling in the pixels, followed by putImageData. I just saw the example in the spec that does just this, but bases the values it puts in on numbers it gets out of getImageData. For that case you would of course want a blank imagedata that matches what getImageData hands out. I still think that we need a better I have some externally-derived pixel data I'd like to just stick in this canvas API here. fillRect() has terrible performance characteristics (as has been brought up many times before), and the current imagedata design makes it very difficult to use it correctly for this purpose... -Boris
Re: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate.
On Mon, 1 Jun 2009, Simon Pieters wrote:
Modified: source
===
--- source 2009-05-30 02:33:07 UTC (rev 3150)
+++ source 2009-05-30 03:49:18 UTC (rev 3151)
@@ -80436,9 +80436,10 @@
form { margin-bottom: 1em; }/pre
pWhen a codeDocument/code is in spanquirks mode/span,
- margins on spanHTML elements/span at the top or bottom of the
- initial containing block, or the top of bottom of codetd/code or
- codeth/code elements, are expected to be collapsed to zero./p
+ margins on spanHTML elements/span at the top or bottom of
+ spanthe body element/span, or the top of bottom of
+ codetd/code or codeth/code elements, are expected to be
+ collapsed to zero./p
h4Alignment/h4
Please change spanthe body element/span to codebody/code elements.
Really? Do you have a test case demonstrating this?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate.
On Mon, 01 Jun 2009 21:09:56 +0200, Ian Hickson i...@hixie.ch wrote: Please change spanthe body element/span to codebody/code elements. Really? Do you have a test case demonstrating this? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/124 -- Simon Pieters Opera Software
Re: [whatwg] [html5] r3151 - [] (0) Try to make the magic margin collapsing rule more accurate.
On Mon, 1 Jun 2009, Simon Pieters wrote: On Mon, 01 Jun 2009 21:09:56 +0200, Ian Hickson i...@hixie.ch wrote: Please change spanthe body element/span to codebody/code elements. Really? Do you have a test case demonstrating this? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/124 Huh. Interesting. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] First or last Content-Type header?
The only case of double headers I can think of is when using scripts that set a content-type, then try to set it again and the language itself don't prevent it. I think the right option in such case would be to follow the last one, as it's the one provided nearer the content. So I vote for using the last one. PS: Interestingly, this behavior could be used to send xhtml (and get it shown on IE) without sending different headers to each browser: Content-Type: text/html Content-Type: application/xhtml+xml
Re: [whatwg] First or last Content-Type header?
Den.Molib wrote on 6/1/2009 4:55 PM: follow the last one, as it's the one provided nearer the content. And by the same logic, the header closest to the content could be the one that was injected by an attacker (via application hole) -- so might choosing the first header be more prudent? - Bil
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell slightly...@google.com wrote:
On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are unique).
What would be the use case in a general object graph?
Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
natural to need it to keep up the facade. In the former, it's a
performance convenience.
If I understand you correctly, you want to subclass the Element interface.
If I got that right, then I am not sure how that concept would relate,
as there are not interfaces in javascript, and so I am not sure how an
object that has the interface of Element could also have the interface
of your subclass. In the could have been ES4, maybe, but that is
would-be fiction now.
I can't think of any reason that anyone would even want that, anyway.
In a fictitious version of javascript where interfaces could be
created, you could just create your own, then implement both in the
target class.
But in reality, you could do something retarded like try to subclass
NodeList. Oh yeah, someone already tried that, didn't they?
Garrett
Re: [whatwg] Exposing EventTarget to JavaScript
On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell slightly...@google.com wrote:
On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
The next and more important step is to allow a JavaScript class to
extend an EventTarget. For example:
function MyClass() {
EventTarget.call(this);
...
}
MyClass.prototype = new EventTarget; // *[1]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are unique).
What would be the use case in a general object graph?
Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
natural to need it to keep up the facade. In the former, it's a
performance convenience.
If I understand you correctly, you want to subclass the Element interface.
Think bigger. I want to create a concrete Element class (that's what a
span is, for all intents and purposes), re-interpret all the other
elements in the DOM class hierarchy in terms of it, and make it
subclassable (or treat it as a Trait for purposes of composition) so
that we can do a component system that lets you introduce new elements
that act sanely both in the HTML and JavaScript senses.
If I got that right, then I am not sure how that concept would relate,
as there are not interfaces in javascript, and so I am not sure how an
object that has the interface of Element could also have the interface
of your subclass. In the could have been ES4, maybe, but that is
would-be fiction now.
I can't think of any reason that anyone would even want that, anyway.
In a fictitious version of javascript where interfaces could be
created, you could just create your own, then implement both in the
target class.
But in reality, you could do something retarded like try to subclass
NodeList. Oh yeah, someone already tried that, didn't they?
...wow. Not sure I should engage with the rest of your message. It's
belligerent for no apparent reason.
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote: Think bigger. I want to create a concrete Element class (that's what a span is, for all intents and purposes) As a minor nit, a span is basically an HTMLElement, not an Element. and make it subclassable (or treat it as a Trait for purposes of composition) so that we can do a component system that lets you introduce new elements that act sanely both in the HTML and JavaScript senses. This has pretty serious security issues of various sorts, depending on what your subclassing would allow you to override. -Boris
[whatwg] Google's use of FFmpeg in Chromium and Chrome Was: Re: MPEG-1 subset proposal for HTML5 video codec
I'd like to address some questions that have been raised about the use of FFmpeg in Chromium and Chrome as well as H.264 decoding in Chrome (Google's distribution of Chromium). The use of FFmpeg in Chromium and Chrome is fully compliant with the obligations of the associated licenses. It feels a little thread/list jacking to do this, but I don't like letting these kinds of questions stand, so... 1. FFmpeg and potential patent license issues FFmpeg is licensed under the LGPL 2.1 (there are some components that are licensed under the GPL but those are not relevant here, as explained below). The LGPL 2.1 states: If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. The LGPL 2.1 only requires that a party distributing LGPL code give other people the same rights to that code that they themselves received under the license. The Chromium project happily does exactly this. Google takes the FFmpeg libraries under the LGPL 2.1, with no attached patent license. Subsequently, Google makes the FFmpeg libraries available as part of Chromium under the LGPL 2.1, with no patent license attached. One participant quoted one of the examples from the LGPL 2.1, which says For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. To be clear, there are two situations here: Situation 1: (a) Party A gives Party B a library licensed under the LGPL 2.1 along with a patent license which says only Party B has the right to use it (b) Party B wants to distribute the library to others That's the situation the example in the LGPL 2.1 text is talking about and would likely be a violation. Situation 2: (a) Party A gives Party B a library licensed under the LGPL 2.1 (b) Party B gets a patent license from Party C (c) Party B then distribute the library under the LGPL 2.1 This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 for a license that does deal with this situation). Under the LGPL 2.1, the fact that Party B may have a patent license with an unrelated third-party is irrelevant as long as it doesn't prevent Party B from granting people the rights LGPL 2.1 requires they grant them (namely, only those rights it in fact received from Party A). 2. Location of FFmpeg source code The source code for FFmpeg is easily locatable in the same place as the rest of the Chromium source: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ 3. GPL licensed code in FFmpeg FFmpeg can be configured to use GPL licensed code, but it is not configured that way in Chromium. We use the set of configuration flags that only enables the LGPL 2.1 code. The list of configuration flags used is listed in the README file in the source directory: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium?revision=16648view=markup We take our obligations under all open source licenses very seriously, and work hard to ensure we are in compliance with these licenses Chris DiBona On Mon, Jun 1, 2009 at 11:21 AM, jjcogliati-wha...@yahoo.com wrote: Thank you for a very informative reply. Inline comments follow. --- On Sun, 5/31/09, Gregory Maxwell gmaxw...@gmail.com wrote: From: Gregory Maxwell gmaxw...@gmail.com Subject: Re: [whatwg] MPEG-1 subset proposal for HTML5 video codec To: whatwg@lists.whatwg.org Date: Sunday, May 31, 2009, 2:17 PM 2009/5/31 jjcogliati-whatwg at yahoo.com: Since the near complete MPEG-1 committee draft was publicly available in December 1991, [snip] You keep repeating this particular piece of misinformation, so I'm worried that people are going to take your word for it and get into trouble. What you are claiming with respect to the inventors disclosure and patent duration is correct for patents filed and granted today but it not true for patents from the mid-1990s. Prior to mid-1995 was possible to use application extensions to defer the grant date of a patent indefinitely. You could begin an application in 1988, publicly expose your invention in 1991, all the while filing extensions only to have the patent granted in 1995. I am somewhat surprised that you are unaware of this issue, considering that you mentioned it specifically by name (submarine patent). Yes, I agree and I was not making this clear in my reply posts. The first email I sent I did detail this. I'm more familiar with the area of audio coding than video, so I don't have a ready list of patents that read on mpeg1 video. However, There are mid-90s patents which read on both layer-2 (e.g. 5,214,678) and layer-3 audio which followed the 'submarine patent' style of prolonged
Re: [whatwg] Exposing EventTarget to JavaScript
On Mon, Jun 1, 2009 at 6:02 PM, Alex Russell slightly...@google.com wrote: On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell slightly...@google.com wrote: On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: Erik Arvidsson wrote: [...] ...wow. Not sure I should engage with the rest of your message. It's belligerent for no apparent reason. The message I am trying to convey -- and let me make this clear -- is that it seems like a really bad idea to even want to try to do that. The subclassing of NodeList has also been attempted before, so one ought to be able to learn from such mistake. I think that makes my intent clearer and disambiguates any disparagement that may have been taken towards persons born with mental retardation[1]. That was not my intent. To those who have relation to such mentally handicapped individuals, my condolences for my careless word choice Garrett
Re: [whatwg] First or last Content-Type header?
2009/6/1 Bil Corry b...@corry.biz: Den.Molib wrote on 6/1/2009 4:55 PM: follow the last one, as it's the one provided nearer the content. And by the same logic, the header closest to the content could be the one that was injected by an attacker (via application hole) -- so might choosing the first header be more prudent? If your site is vulnerable to header splitting, then you have bigger problems than injecting a Content-Type header. In any case, the four major browsers that actually look at the Content-Type header agree and use the last header. The only browser that uses the first header more or less ignores it anyway. Adam
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
Also sprach Chris DiBona: To be clear, there are two situations here: Situation 1: (a) Party A gives Party B a library licensed under the LGPL 2.1 along with a patent license which says only Party B has the right to use it (b) Party B wants to distribute the library to others That's the situation the example in the LGPL 2.1 text is talking about and would likely be a violation. Situation 2: (a) Party A gives Party B a library licensed under the LGPL 2.1 (b) Party B gets a patent license from Party C (c) Party B then distribute the library under the LGPL 2.1 This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 for a license that does deal with this situation). Under the LGPL 2.1, the fact that Party B may have a patent license with an unrelated third-party is irrelevant as long as it doesn't prevent Party B from granting people the rights LGPL 2.1 requires they grant them (namely, only those rights it in fact received from Party A). Thanks for your willingness to discuss these matters. So, to be clear, you're saying that situation 2 applies in your case? -hkon Håkon Wium Lie CTO °þe®ª howc...@opera.com http://people.opera.com/howcome
