I installed the FireFox 3.5 Beta to try out the new HTML5 Video Tag. dailymotion open video demo (source)
I like how it says “this will never work in internet explorer”
Too early to really evaluate compared with flash, although I expect both performance and quality will be better without the extra bubble of flash running. I would like to get an early start supporting this feature.
Just tested firebug-1.4.0a30.xpi available At top of this list works fine in FireFox 3.5 Beta
Here is a Cool Post Explaining Using the HTML5 <video> tag with a Flash fallback
I just tested fixed position performance of HTML5 video, and Its far from stellar right now. I think this is because of two things: the large number of elements being rendered, and some code that is not realizing that the elements do not move or go off the screen but moves them each time to keep up with the current scroll? Its slightly more complex to grab the entire element now, because you cannot simply grab the video tag, because the controls are up one level, and the container is up two levels. As long as its predictably up two levels like this then its going to be simple to automate grabbing the entire player, although since sometimes that div has a size and the video also has a size, and the controls could potentially have a size, resizing the video and accounting for the controller size automatically isn’t so simple as it was before. Please donate to support continued development!
Each fixed position element ought to be rendered like a completely separate logical webpage that is then stacked at some level in the draw stack for the current page, but merely as far as ordering goes, no repositioning should be necessary since the fixed position element is rendered at its own offset from 0,0 the effect is simply an overlay, the absence of any additional transformation while scrolling… I mean I guess position-fixed unfortunately and almost uselessly needs support for z-index, although I can imagine one or two futuristic applications that might like to overlay another fixed position element, the stacking of position relative or position absolute on top of a position fixed element seems less likely to be useful in any serious way, it makes sense to keep that possible, even if it should be handled as a separate case which is almost certainly slower to render, where when it can simply be drawn last, then it should be the fastest solution. A fixed position element with the largest z-index can always be rendered last and on top of whatever else was there before, without doing anything besides reset the “world transform” leaving the “object transform” intact. Its possible to encode the offset distance in the first pixel of the texture or otherwise and pull off with a pixel shader. If there is enough memory it makes complete sense when dealing with position fixed to create a texture out of the web page itself and merely snap rectangles from it to the screen while scrolling, so that rendering performance of fixed position elements can stay at one hundred percent. I mean any vector sketching or redundant stamping operations need to be cached and reused while generating content while scrolling however… and any buffer that is generated while scrolling should be saved until you stop scrolling… the word the for instance… and small rectangles on the texture may need to be updated due to interaction or script. Ideally all fixed position elements should create textures which are then merely unlocked and stamped to the screen at the correct time, and updated via thread that handles rendering user interface updates for that element as stamped regions of texture (2 stamps, for video and play head). Automatic recognition of duplicate elements large enough in size composed of enough smaller draw calls but used frequently enough to cache ought to be cached, and ideally other textures are a simple texture transformation away from the last one and undoing changes is as instantaneous as playing back the transformation map in reverse for a particular quad, and the most interesting thing is that the transformation maps can theoretically operate at much lower resolution than screen space and still achieve crisp results since the distance between the data is almost certainly less than the resultant data itself, and rarely involves all color channels. I’m not sure why its not like this already unless we are waiting on some new type of hardware that in effect looks like memory, but its really a memory stacking unit that generates data comprised of various pieces of system memory logically operated on and stacked in real time… as fast as if accessing out of memory itself, but that sounds a lot like an LCD screen to me… but picture two blocks of memory being access simultaneously and you receive the logical AND of each as fast as you could receive either block independently, like some sort of zipper… except it doesn’t stop at logical AND… plus sections of memory containing zero or one, could have additional memory mapped right on top of the same memory space at a different scale and maintain one hundred percent of all data, in which case storing a black object as an inverted white object or vice versa makes perfect sense and can simply be logically NOT on the way out, meanwhile memory at a different scale (say 512 on a 2048) seems technically feasible however scary it might seem. I mean theoretically its possible to stack as many transformation on the same memory space as your capable or indexing, and there aren’t any rules saying that you can’t stack on the index space as well but the consequence of doing any of this stuff would be horrible parasitically increasing slowness… that is unless any number of memory quadrants of any shape could be stacked instantaneously, which sounds a bit too much like quantum computing for today.
Please donate to support continued development!