[whatwg] Fwd: [ORG-discuss] BBC video codec to become an international standard
-- Forwarded message -- From: Glyn Wintle [EMAIL PROTECTED] Date: 25 Jan 2008 01:15 Subject: [ORG-discuss] BBC video codec to become an international standard To: Open Rights Group open discussion list [EMAIL PROTECTED] First linked to by groklaw http://sonofid.blogspot.com/2008/01/on-road-to-dirac-standard-at-last.html Ok, so I know that people think that Dirac disappeared into a black hole some while ago but we're still hanging in there and getting it done. We're just coming up to some really major milestones and things are looking really exciting. First, Dirac (or part of it) is going to be an international standard. Yay! We made a cut-down version doing intra coding only and this has only just been submitted to the SMPTE. If it goes through it will become VC-2 (Windows Media 9 became VC-1 when they standardised it). After a lot of hard work fighting SMPTE's preferred Word format (yuk) it went in just before Christmas and is being voted on as a Committee Draft as I write this. At the same time we've been updating the full spec and that's been published today. Version 1.0 covers the professional VC-2 stuff, whilst version 2.0 covers the whole system. If VC-2 is well-received we'll propose an extension so that it covers the whole of Dirac. Then at last there'll be a royalty-free video compression standard ... Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ ORG-discuss mailing list [EMAIL PROTECTED] http://lists.openrightsgroup.org/mailman/listinfo/org-discuss
Re: [whatwg] More random comments on the putImageData definition
So I came across this wonderful piece of javascript: http://jsmsxdemo.googlepages.com/jsmsx.html If present it uses putImageData (and getImageData to get the ImageData object, which isn't required by html5 now -- and i think hixie was look at doing some more work with ImageData). With the current model for putImageData there is no way for them to specify a dirty rect, which means their only option is to update the entire display -- they have to copy the entire buffer. If putImageData were to take an optional dirty rect parameter we could reduce the amount of work necessary, and still maintain backwards compatibility. My attention was drawn to this as a brief bit of hackery in webkit showed that the above webapp only updates the necessary dirty parts of a frame and yet Opera and Firefox both *have* to copy, blit and repaint the entire canvas, ironically because they both provide the faster get/putImageData API's (this is not to suggest either implementation is in any way slow, just that it seems we are missing a perfectly reasonable API to improve performance beyond what has already been achieved). Anyway, i was thinking we would just need to putDataImage methods: void putImageData(in ImageData imagedata, in float dx, in float dy); void putImageData(in ImageData imagedata, in float dx, in float dy, in float dirtyX, in float dirtyY, in float dirtyWidth, in float dirtyHeight); Where the dirtyX and dirtyY are relative to the ImageData's origin. The repaint region would be (dx+dirtyX, dy+dirtyY), dirtyWidth*dirtyHeight in the canvas domain, and (more importantly) only that subsection of the ImageData would need to be copied, and in the case of those UAs that need it, unpremultiplied. This could result in significant gains for more complex uses of canvas, like the one above. Compatibility: If the dirty rect is provided to a UA that doesn't support it (eg. new content in old/current Opera, Firefox) the entire ImageData will be blitted as would currently be expected (opera and firefox both ignore extraneous arguments on putImageData, i'm not sure about konqueror/ khtml). If a dirty rect is not provided (eg. old content in a newer UA) the entire block would be considered dirty, and so repaint as expected. Any thoughts? --Oliver On Jan 23, 2008, at 11:28 AM, Oliver Hunt wrote: On 23/01/2008, at 5:44 AM, Philip Taylor wrote: On 23/01/2008, Oliver Hunt [EMAIL PROTECTED] wrote: It would be great if putImageData could take a source region, in addition to the destination. One of the primary reasons for using get/putImageData is to allow JS to rapidly blit data to the screen, however without an ability to blit only a subregion of the image data the only available options are to either re-blit the entire imagedata region (which can be expensive due to the need for [un]premultiplying in some (all?) implementations), ((Opera does non-premultiplied colour internally.)) Righto. There's still the necessary type/range checking involved at some point. or create and populate a new ImageData object which still requires more work than would ideally be necessary. You can also create a temporary canvas and putImageData once onto that, and then drawImage sections onto the screen as they are needed. That lets you draw lots of sections lots of times quickly (since you're mostly drawing from the optimised canvas surface format, not from a JS array), which perhaps helps in some (most?) of the cases. (You still have to do a single putImageData of the whole data to get it onto the temporary canvas, but if there are parts of the data you aren't ever using then you just should make the ImageData smaller and cut out the unused bits.) Yes, there are many ways you can resolve this if you're willing to copy data around in JS, which is far less efficient than letting you use your single backing buffer, but only (effectively) repainting part of it. Using a separate canvas also works, but still requires additional copying, much more memory, and the use of drawImage which doesn't have the same semantics as putImageData. --Oliver -- Philip Taylor [EMAIL PROTECTED]
Re: [whatwg] More random comments on the putImageData definition
On Jan 25, 2008, at 6:56 AM, Oliver Hunt wrote: With the current model for putImageData there is no way for them to specify a dirty rect, which means their only option is to update the entire display -- they have to copy the entire buffer. snip Anyway, i was thinking we would just need to putDataImage methods: void putImageData(in ImageData imagedata, in float dx, in float dy); void putImageData(in ImageData imagedata, in float dx, in float dy, in float dirtyX, in float dirtyY, in float dirtyWidth, in float dirtyHeight); Where the dirtyX and dirtyY are relative to the ImageData's origin. The repaint region would be (dx+dirtyX, dy+dirtyY), dirtyWidth*dirtyHeight in the canvas domain I think it would be less confusing for the repaint region to always have its origin at (dx, dy). This would be more similar to Windows' BitBlt API. Something like: void putImageData(in ImageData imageData, in float destX, in float destY, in float srcX, in float srcY, in float width, in float height) destX and destY are in canvas coordinates srcX and srcY are in ImageData coordinates The data from the ImageData in the rectangle specified by (srcX, srcY, width, height) is then painted into the canvas in the rectangle (destX, destY, width, height). -Adam
[whatwg] accesskey
In the present standard you are alowd to use the same accesskey in to different links... For example: a href=bob.html accesskey=bBob web page/a a href=bob.html accesskey=bBob web page/a But what would happend if this was to happend: a href=bob.html accesskey=bBob web page/a a href=alex.html accesskey=bAlex web page/a Again this is allowed in the present web standard, but if you think about it its illogical, on what bases thus the browser decide wich one to access first or should it open the tow?
Re: [whatwg] accesskey
Why are there removing accesskey? http://www.w3.org/TR/html5-diff/#absent-attributes I though it was recommended to be used by WAI... What are we should we use? Because its not said what accesskey is replace with...
Re: [whatwg] accesskey
Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. The intended replacement is the XHTML Role Access Modulehttp://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule. It works in a manner similar to accesskeys, but attempts to resolve some of the original shortcomings. I'm afraid I'm not intimately familiar with it, but I believe it also resolves the original multi-mapping problem you brought up. A few links on the subject: http://www.cs.tut.fi/~jkorpela/forms/accesskey.html The original version of this document had a much more positive attitude to the accesskey attribute. Experience and analysis has shown, however, that the idea of author-defined shortcuts is generally not useful on the Web. Moreover, serious damage is often caused by the way in which the attribute has been implemented in browsers: it uses key combinations that override built-in functionality in browsers and other software. Unfortunately, browser support to the attribute is limited, and rather primitive. The accesskey attribute tends to mask out the functionality of a browser's predefined keyboard control, which is often much more important than page-specific access keys. Moreover, browsers do not indicate that access keys are available. http://en.wikipedia.org/wiki/Access_keys In the summer of 2002, a Canadian Web Accessibility consultancy did an informal survey to see if implementing accesskeys caused issues for users of adaptive technology http://en.wikipedia.org/wiki/Adaptive_technology, especially screen reading technology used by blind and low vision users. These users require numerous keyboard shortcuts to access web pages, as pointing and clicking a mouse is not an option for them. Their research showed that most key stroke combinations did in fact present a conflict for one or more of these technologies, and their final recommendation was to avoid using accesskeys altogether. The World Wide Web Consortium http://www.w3.org/, the organization responsible for establishing internet standards, has acknowledged this short-coming, and in their latest draft documents for a revised web authoring language (XHTML 2http://www.w3.org/TR/2005/WD-xhtml2-20050527/), they have deprecated (retired) the ACCESSKEY attribute in favor of the XHTML Role Access Modulehttp://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule . http://www.wats.ca/show.php?contentid=32 *So while it seems that Accesskeys is a great idea in principle, implementation brings with it the possibility that it either will not be available to all users, or that the keystroke combination encoded within the web page may conflict with a reserved keystroke combination in an adaptive technology or future user agent.* This potential problem was subsequently brought to the attention of the Canadian Common Look and Feel Access Working Group (who had previously suggested the use of Accesskeys M, 1 and 2), and after consideration the Access Working Group reversed it's recommendation and now suggest *not* to use Accesskeys on Government of Canada Web sites. Thanks, Jerason On Jan 25, 2008 10:43 PM, Jean-Nicolas Boulay Desjardins [EMAIL PROTECTED] wrote: Why are there removing accesskey? http://www.w3.org/TR/html5-diff/#absent-attributes I though it was recommended to be used by WAI... What are we should we use? Because its not said what accesskey is replace with...
Re: [whatwg] Reverse ordered lists
I have to agree CSS would be the best way. But is it rely use full to have in CSS order:... Could you just do it with JavaScript... I think that we should add new properties to CSS but I don't think its a good idea to over load CSS with every new properties that we come up with, that we might not even use... For example if I wanted to change the order of a list I would use a server side code or JavaScript... I don't think we want CSS to become a over blown language... This is what I think... There is maybe good arguments to add it to CSS... But for now I think that server side code and JavaScript can do the job, plus with JavaScript you have more power, its some think to think about...
Re: [whatwg] More random comments on the putImageData definition
On Fri, 25 Jan 2008 23:57:56 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: Another thing that we need is some way to determine what the device pixel-css pixel ratio is. Currently there's isn't even a real way to tell that it's 1:1 -- you would have do do a fillRect(width-1, height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see if they match. Conceivably you could do this multiple times to estimate the ratio, but it would be non-trivial. You can determine this by checking the height and width attributes on the ImageData object. If you get a 2x2 region and ImageData.width and .height return 4 you know there's a factor two scaling happening between canvas pixels and device pixels. What the factor is between canvas pixels and CSS pixels isn't really relevant (and easy to determine). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] More random comments on the putImageData definition
On Fri, 25 Jan 2008 23:56:28 +0100, Maciej Stachowiak [EMAIL PROTECTED] wrote: getImageData/putImageData will definitely cause problems for high-DPI displays in the future that are driven with a scale factor where CSS pixels are not device pixels. The question is whether it's better for some content to fail and other content to work (if it checks the returned width/height), or for all content to lose resolution relative to what the display is capable of. Note that we already have a difference between canvas pixels and CSS pixels. One could easily do this for high definition displays: canvas height=1000 width=1000 style=height:100px;width:100px (Might be a bit much.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] More random comments on the putImageData definition
On Jan 25, 2008, at 2:30 PM, Anne van Kesteren wrote: On Fri, 25 Jan 2008 21:00:41 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: [...] I had a question as I still think ImageData should be simplified. Are you planning to support high resolution ImageData objects? As specified ImageData is in device pixels rather than in canvas pixels yet no browsers support this and last we checked content is already assuming otherwise. getImageData/putImageData will definitely cause problems for high-DPI displays in the future that are driven with a scale factor where CSS pixels are not device pixels. The question is whether it's better for some content to fail and other content to work (if it checks the returned width/height), or for all content to lose resolution relative to what the display is capable of. Regards, Maciej
Re: [whatwg] Form submission progress display by UA (incl. file upload)
timeless wrote:
On 1/24/08, Mikko Rantalainen [EMAIL PROTECTED] wrote:
I think that WF2 section 5.6
(http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes)
should be modified to say something along the lines
User agents with interactive user interfaces should inform the user
about the progress of the data submission. For example, an UA with a
graphical user interface could display a visual progress bar which would
be updated once every second; the bar would be initially displayed as
empty and would fill over time as the encoded form data set is
transmitted. For transmissions that take more than a few seconds UA
might in addition display estimated time before done.
My embedded device battery managers will complain about anything that
happens more than once every 30s (they do).
It's wise to always trying to minimize the battery usage in a battery
operated device. However, if the device is already using wireless or
wired communication for transmitting the data set it cannot just do
nothing. Notice, also, that I wasn't suggesting that the above text is
a MUST but instead just SHOULD. Perhaps it could be even recommended.
[an user uploading a huge file over slow uplink] in a hurry would
hit stop button and retry again after waiting for some time without
knowing that upload is in progress.
I think a slightly more beneficial thing would be for the file picker
posting system to be able to tell the user how big the file is and how
long submitting a form should take at some transfer time. I'm not sure
if anything like this is exposed.
How can the file picker posting system know something like actual
bandwidth beforehand? Perhaps the user is using a mobile device that is
currently on WLAN connection (say 54mbps) and the user starts sending
the file. If the file picker has told the user that sending takes
approximately 5 minutes for the selected file, how is the user supposed
to know the actual sending time after he starts moving and the
connection drops to 3G mobile network (around 0.5mbps) or GPRS or GSM
data mobile network (around 0.001mbps). I cannot imagine anything but a
progress bar displaying the current rate (or transfer rate for the
previous 30 seconds if that's how often the progress can be updated
because the battery must be conserved).
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
lists a fileSize property. I think it'd be nice if gmail could tell me
that this file will take an hour to upload. I also wonder if it'd be
a good idea to support getting chunks of a file, because if I had a
4gb file, using DOMFile().getAsBinary() would probably crash my
browser. I'd kinda like for gmail to be able to do partial uploads
In order for this to work, there should be DOMString hash() which has
an optional argument for a hash algorithm (md5sum, a const for
md5sum, or maybe an object { processBlock:function(data) {},
getHash:function() }. Otherwise a user could try feeding sequential
blocks from different files.
I agree that something like that would be nice to have for some cases.
However, I do not think that such behavior would make upload progress
monitoring unneeded. The current fix for this problem is to connect
the receiving server with HttpXmlRequest() and ask the server how much
data the server has received. Then this result can be displayed somehow
to the user.
Currently, file uploading is a kinda syncish process.
As to your actual concerns, gmail already deals w/ uploading in the
background fairly gracefully. And in IE6, there is a progress meter
during the upload (Gecko doesn't show proper progress, but I believe
that's a bug).
I don't think that IE has a working upload progress meter. I have always
experienced IE just to simply slowly increase the progress meter until
the page is done; it's advancing even if I disconnect the network cable
during the progress... (just tried IE6 and IE7)
I'm not sure I see what value is added by somehow mandating this
feature. Evolving browsers will probably add this feature anyway
through competition.
If it will probably be added in the future anyway shouldn't the spec
recommend doing so sooner? I'm not saying that every UA MUST do so but
they should (unless they have a good reason not to).
--
Mikko
signature.asc
Description: OpenPGP digital signature
Re: [whatwg] Opera SVG Re: How to use SVG in HTML5?
Hi Charles, Thanks for looking into this. Here you go: http://xhtml.com/misc/svg-img1.htm http://xhtml.com/misc/svg-img2.htm http://xhtml.com/misc/svg-img3.htm Regards, -Vlad http://xhtml.com Original Message From: Charles McCathieNevile Date: 2008-01-24 10:47 PM Hi Vlad, On Fri, 25 Jan 2008 00:50:45 +1100, Vlad Alexander (xhtml.com) [EMAIL PROTECTED] wrote: ... I tested Opera's support for SVG through the img element and it incorrectly clips the SVG image. The width and height attributes of the img element need to set the viewport for the SVG image and scale the SVG non-uniformly to fit the viewport. What was your test case? Can you share it so we can check whether this is a known problem or issue? cheers Chaals
Re: [whatwg] More random comments on the putImageData definition
Another thing that we need is some way to determine what the device pixel-css pixel ratio is. Currently there's isn't even a real way to tell that it's 1:1 -- you would have do do a fillRect(width-1, height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see if they match. Conceivably you could do this multiple times to estimate the ratio, but it would be non-trivial. --Oliver On Jan 25, 2008, at 2:30 PM, Anne van Kesteren wrote: On Fri, 25 Jan 2008 21:00:41 +0100, Oliver Hunt [EMAIL PROTECTED] wrote: [...] I had a question as I still think ImageData should be simplified. Are you planning to support high resolution ImageData objects? As specified ImageData is in device pixels rather than in canvas pixels yet no browsers support this and last we checked content is already assuming otherwise. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Reverse ordered lists
To add to what Christoph is saying, perhaps there's a better way to look at this problem? A reverse list has both a start and an end, just like any other list. The key is that it's displayed in the opposite order of a regular list. This raises the question, why does the list need to be *serialized* in reverse order? Given that it's a display attribute, wouldn't it make more sense to force the UA into rendering the list in reverse? e.g.: ol style=order: reverse; lione/li litwo/li lithree/li lifour/li lifive/li /ol Which would then render like this: 5. five 4. four 3. three 2. two 1. one This also solves the partial render problem as the list would partial render as follows. Step 1: 1. one Step 2: 2. two 1. one Step 3: 3. three 2. two 1. one Step 4: 4. four 3. three 2. two 1. one Step 5: 5. five 4. four 3. three 2. two 1. one Obviously this solution puts a bit more of the onus on the User Agent to render the list correctly, but I think it's semantically more correct than trying to encapsulate the display data in the DOM ordering. This also provides backward compatibility as UAs that don't understand the reverse attribute will still number the list correctly. (Whereas the previous solutions would result in the numbering being reversed in older browsers.) Thanks, Jerason On Jan 25, 2008 11:29 AM, Christoph Päper [EMAIL PROTECTED] wrote: Simon Pieters: It was pointed out to me that the start='' attribute (and the corresponding DOM attribute) currently defaults to 1. This could, AFAICT, reaonably trivially be changed to make it depend on the direction of the list and the number of li children. Or you would introduce an |end| attribute, because 'start' is not the same as 'first'... I think it has been shown, that the meta attribute |reverse| would not work in HTML, it would have to be a command attribute, i.e. it doesn't describe the ordering of the following list items, but their indended display. This would make it presentational and thereby not suitable for HTML. It would belong into CSS, but that isn't very good at reordering boxes.
Re: [whatwg] Reverse ordered lists
Simon Pieters: It was pointed out to me that the start='' attribute (and the corresponding DOM attribute) currently defaults to 1. This could, AFAICT, reaonably trivially be changed to make it depend on the direction of the list and the number of li children. Or you would introduce an |end| attribute, because 'start' is not the same as 'first'... I think it has been shown, that the meta attribute |reverse| would not work in HTML, it would have to be a command attribute, i.e. it doesn't describe the ordering of the following list items, but their indended display. This would make it presentational and thereby not suitable for HTML. It would belong into CSS, but that isn't very good at reordering boxes.
Re: [whatwg] More random comments on the putImageData definition
On Jan 25, 2008, at 6:53 AM, Adam Roben wrote: On Jan 25, 2008, at 6:56 AM, Oliver Hunt wrote: With the current model for putImageData there is no way for them to specify a dirty rect, which means their only option is to update the entire display -- they have to copy the entire buffer. snip I think it would be less confusing for the repaint region to always have its origin at (dx, dy). This would be more similar to Windows' BitBlt API. Something like: void putImageData(in ImageData imageData, in float destX, in float destY, in float srcX, in float srcY, in float width, in float height) destX and destY are in canvas coordinates srcX and srcY are in ImageData coordinates The data from the ImageData in the rectangle specified by (srcX, srcY, width, height) is then painted into the canvas in the rectangle (destX, destY, width, height). The problem in that case is that it would not be backwards compatible -- eg. puImageData(data, destx, desty, srcx, srcy, width, height) If the UA supports dirty region mapping then it would effectively be mapping (0,0) on the ImageData to (destx - srcx, desty - srcy), whereas a UA that does not support dirty regions would be mapping (0,0) to (destx,desty) and so wouldbe broken. That's why i said the dirty rect should be relative to the imagedata origin, i also feel it makes more sense to say this area of the imagedata is the interesting bit rather than once you've blitted, this area of the *canvas* will be interesting --Oliver -Adam
