Re: [whatwg] Quirks mode handling of rowspan=0
2012-09-03 3:11, Boris Zbarsky wrote: Per HTML5 spec, rowspan=0 should span to the end of the table section. This was the case already in HTML 4.01, though it was implemented slowly and was not much known among authors. In any case, my suggestion is that in quirks mode, rowspan=0 not be supported. Generally, attempts at defining quirks mode would mean making it an alternate mode and will not be successful due to the wide variation across browsers and versions. It's called quirks for a reason. Specifically, as some browsers already support rowspan=0 in quirks mode, and some don't, you cannot ensure backwards compatibility no matter how you define it. For the bulk of legacy pages, it does not really matter, as they do not use such attributes. So the question is really what happens to newer pages where people may have used them after observing that some browsers support them. The current situation is inconsistent across browsers, but it does not help to change it; it could break existing pages written to work on browsers that support rowspan=0 in quirks mode. Similar considerations apply to colspan=2. Yucca
Re: [whatwg] Quirks mode handling of rowspan=0
On Mon, 03 Sep 2012 02:11:44 +0200, Boris Zbarsky bzbar...@mit.edu wrote: Per HTML5 spec, rowspan=0 should span to the end of the table section. WebKit seems to not implement this at all. Opera implements this in quirks and standards mode. Gecko implements this in standards mode only; in quirks mode, rowspan=0 is treated like rowspan=1. When we last tried to do the right thing in quirks mode, back in 2003 or so, we ran into site compatibility issues, hence the current setup. I don't know what Trident does here; worth testing. In any case, my suggestion is that in quirks mode, rowspan=0 not be supported. Is there a compat problem with supporting it in quirks mode? I'm not aware of Opera having problems with it. -- Simon Pieters Opera Software
Re: [whatwg] Hardware accelerated canvas
On Mon, 03 Sep 2012 00:14:49 +0200, Benoit Jacob bja...@mozilla.com wrote: - Original Message - On Sun, 2 Sep 2012, Erik Möller wrote: As we hardware accelerate the rendering of , not just with the webgl context, we have to figure out how to best handle the fact that GPUs loose the rendering context for various reasons. Reasons for loosing the context differ from platform to platform but ranges from going into power-save mode, to internal driver errors and the famous long running shader protection. A lost context means all resources uploaded to the GPU will be gone and have to be recreated. For canvas it is not impossible, though IMO prohibitively expensive to try to automatically restore a lost context and guarantee the same behaviour as in software. The two options I can think of would be to: a) read back the framebuffer after each draw call. b) read back the framebuffer before the first draw call of a frame and build a display list of all other draw operations. Neither seem like a particularly good option if we're looking to actually improve on canvas performance. Especially on mobile where read-back performance is very poor. The WebGL solution is to fire an event and let the js-implementation deal with recovering after a lost context http://www.khronos.org/registry/webgl/specs/latest/#5.15.2 My preferred option would be to make a generic context lost event for canvas, but I'm interested to hear what people have to say about this. Realistically, there are too many pages that have 2D canvases that are drawn to once and never updated for any solution other than don't lose the data to be adopted. How exactly this is implemented is a quality of implementation issue. With all the current graphics hardware, this means don't use a GL/D3D surface to implement the 2d canvas drawing buffer storage, which implies: don't hardware-accelerate 2d canvases. If we agree that 2d canvas acceleration is worth it despite the possibility of context loss, then Erik's proposal is really the only thing to do, as far as current hardware is concerned. Erik's proposal doesn't worsen the problem in anyway --- it acknowledges a problem that already exists and offers to Web content a way to recover from it. Hardware-accelerated 2d contexts are no different from hardware-accelerated WebGL contexts, and WebGL's solution has been debated at length already and is known to be the only thing to do on current hardware. Notice that similar solutions preexist in the system APIs underlying any hardware-accelerated canvas context: Direct3D's lost devices, EGL's lost contexts, OpenGL's ARB_robustness context loss statuses. Benoit -- Ian Hickson U+1047E)\._.,--,'``. fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' I agree with Benoit, this is already an existing problem, I'm just pointing the spotlight at it. If we want to take advantage of hardware acceleration on canvas this is an issue we will have to deal with. I don't particularly like this idea, but for the sake of having all the options on the table I'll mention it. We could default to the old behaviour and have an opt in for hardware accelerated canvas in which case you would have to respond to said context lost event. That would allow the existing content to keep working as it is without changes. It would be more work for vendors, but it's up to every vendor to decide how to best solve it, either by doing it in software or using the expensive read back alternative in hardware. Like I said, not my favourite option, but I agree it's bad to break the web. -- Erik Möller Core Gfx Lead Opera Software twitter.com/erikjmoller
Re: [whatwg] Hardware accelerated canvas
On Mon, 03 Sep 2012 03:37:24 +0200, Charles Pritchard ch...@jumis.com wrote: Canvas GPU acceleration today is done via transform3d and transitions. I hope everyone are aware that this connection is just coincidental. The fact that one vendor decided to flip the hardware acceleration switch when there was a 3d-transform doesn't mean everyone will. Hardware acceleration and 3d-transforms are separate features. 3d transforms should be available in software rendering as well. Most [installed] GPUs are not able to accelerate the Canvas path drawing mechanism. They are able to take an array of floats for WebGL, though. It's true that there are no dedicated hardware for rendering paths in the GPUs of today, but they are very good at rendering line segments and triangle strips and paths can be triangulated. With some preprocessing paths can even be rendered directly using shaders http://research.microsoft.com/en-us/um/people/cloop/loopblinn05.pdf What is really meant here by Canvas GPU acceleration? I can of course only speak for Opera, but we strive to hardware accelerate all parts of the drawing, and for canvas that also entails triangulating paths and batching to reduce the number of drawcalls. I.e. using an image atlas to draw several pieces in succession should give a good performance boost. Of course if we'd want to take it one step further then adding support at the API level for drawing multiple images would be good. -- Erik Möller Core Gfx Lead Opera Software twitter.com/erikjmoller
Re: [whatwg] Hardware accelerated canvas
- Original Message - On Mon, 03 Sep 2012 00:14:49 +0200, Benoit Jacob bja...@mozilla.com wrote: - Original Message - On Sun, 2 Sep 2012, Erik Möller wrote: As we hardware accelerate the rendering of , not just with the webgl context, we have to figure out how to best handle the fact that GPUs loose the rendering context for various reasons. Reasons for loosing the context differ from platform to platform but ranges from going into power-save mode, to internal driver errors and the famous long running shader protection. A lost context means all resources uploaded to the GPU will be gone and have to be recreated. For canvas it is not impossible, though IMO prohibitively expensive to try to automatically restore a lost context and guarantee the same behaviour as in software. The two options I can think of would be to: a) read back the framebuffer after each draw call. b) read back the framebuffer before the first draw call of a frame and build a display list of all other draw operations. Neither seem like a particularly good option if we're looking to actually improve on canvas performance. Especially on mobile where read-back performance is very poor. The WebGL solution is to fire an event and let the js-implementation deal with recovering after a lost context http://www.khronos.org/registry/webgl/specs/latest/#5.15.2 My preferred option would be to make a generic context lost event for canvas, but I'm interested to hear what people have to say about this. Realistically, there are too many pages that have 2D canvases that are drawn to once and never updated for any solution other than don't lose the data to be adopted. How exactly this is implemented is a quality of implementation issue. With all the current graphics hardware, this means don't use a GL/D3D surface to implement the 2d canvas drawing buffer storage, which implies: don't hardware-accelerate 2d canvases. If we agree that 2d canvas acceleration is worth it despite the possibility of context loss, then Erik's proposal is really the only thing to do, as far as current hardware is concerned. Erik's proposal doesn't worsen the problem in anyway --- it acknowledges a problem that already exists and offers to Web content a way to recover from it. Hardware-accelerated 2d contexts are no different from hardware-accelerated WebGL contexts, and WebGL's solution has been debated at length already and is known to be the only thing to do on current hardware. Notice that similar solutions preexist in the system APIs underlying any hardware-accelerated canvas context: Direct3D's lost devices, EGL's lost contexts, OpenGL's ARB_robustness context loss statuses. Benoit -- Ian Hickson U+1047E)\._.,--,'``. fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' I agree with Benoit, this is already an existing problem, I'm just pointing the spotlight at it. If we want to take advantage of hardware acceleration on canvas this is an issue we will have to deal with. I don't particularly like this idea, but for the sake of having all the options on the table I'll mention it. We could default to the old behaviour and have an opt in for hardware accelerated canvas in which case you would have to respond to said context lost event. Two objections against this: 1. Remember this adage from high-performance computing which applies here as well: The fast drives out the slow even if the fast is wrong. Browsers want to have good performance on Canvas games, demos and benchmarks. Users want good performance too. GL/D3D helps a lot there, at the cost of a rather rare -- and practically untestable -- problem with context loss. So browsers are going to use GL/D3D, period. On the desktop, most browsers already do. It seems impossible for the spec to require not using GL/D3D and get obeyed. 2. This would effectively force browsers to ship an implementation that does not rely on GL/D3D. For browsers that do have a GL/D3D based canvas implementation and target platforms where GL/D3D availability can be taken for granted (typically on mobile devices), it is reasonable to expect that in the foreseeable future they might want to get rid of their non-GL/D3D canvas impl. Benoit That would allow the existing content to keep working as it is without changes. It would be more work for vendors, but it's up to every vendor to decide how to best solve it, either by doing it in software or using the expensive read back alternative in hardware. Like I said, not my favourite option, but I agree it's bad to break the web. -- Erik Möller Core Gfx Lead Opera Software
Re: [whatwg] Hardware accelerated canvas
- Original Message - What is really meant here by Canvas GPU acceleration? This means use GL/D3D to implement the 2D canvas drawing primitives; but what really matters here, is that this requires using a GL/D3D texture/surface as the primary storage for the 2D canvas drawing buffer. Because of the way that current GPUs work, this entails that the canvas drawing buffer is a /discardable/ resource. Erik's proposal is about dealing with this dire reality. Again, accelerated canvases have been widely used for a year and a half now. It's not realistic to expect the world to go back to non-accelerated by default now. Benoit
Re: [whatwg] Quirks mode handling of rowspan=0
On 9/3/12 2:31 AM, Jukka K. Korpela wrote: This was the case already in HTML 4.01 Yes, I know. Generally, attempts at defining quirks mode would mean making it an alternate mode and will not be successful due to the wide variation across browsers and versions. It's called quirks for a reason. See http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html The point is to enable new UAs to be written that can actually function on the web. That means specifying quirks mode. Specifically, as some browsers already support rowspan=0 in quirks mode, and some don't, you cannot ensure backwards compatibility no matter how you define it. This is not specific to quirks mode. This happens any time there's lack of interop. It's not a new situation. but it does not help to change it Yes, it does: once all browsers agree, the barrier to entry for new entrants is lower because they just need to implement the behavior everyone already agrees on. -Boris
Re: [whatwg] Quirks mode handling of rowspan=0
On 9/3/12 3:25 AM, Simon Pieters wrote: Is there a compat problem with supporting it in quirks mode? I did cover this in my post. The last time we tried it, there was, but that was a while ago. -Boris
Re: [whatwg] Canvas roundedRect
On Thu, 21 Jun 2012, Igor Trindade Oliveira wrote:
Currently, canvas2d does not have support for rounded rectangles and
the web developers are implementing rounded rectangles using arcs or
bezier curves.[1][2]
The arcTo() method is very specifically designed to enable rounded
rectangles to be done relatively easily:
function roundRect(c, x, y, w, h, r) {
if (r w/2)
r = w/2;
if (r h/2)
r = h/2;
c.beginPath();
c.moveTo(x+w/2, y);
c.arcTo(x+w, y, x+w, y+h/2, r);
c.arcTo(x+w, y+h, x+w/2, y+h, r);
c.arcTo(x, y+h, x, y+h/2, r);
c.arcTo(x, y, x+w/2, y, r);
c.closePath();
c.stroke();
}
I don't think we need to add a feature to the API just for this.
On Thu, 21 Jun 2012, David Dailey wrote:
I have seen how the canvas folks like to re-invent wheels
Actually we try to reuse SVG's solutions where possible.
On Thu, 21 Jun 2012, Bronislav Klu�~Mka wrote:
So why do ve have rect? 4 lines could do it... simple enough...
We have rect() mostly for historical reasons -- it was included in the API
that Apple implemented.
If we would go for round rect (RR), we need the obility to create RR
paths and the ability to create each corner different - specify x and
y radiuses for every corner
That's relatively easy to do as well:
function roundRect(c, x, y, w, h, r1, r2, r3, r4) {
// assumes that r1..r4 are in range
c.beginPath();
c.moveTo(x+w/2, y);
c.arcTo(x+w, y, x+w, y+h/2, r1);
c.arcTo(x+w, y+h, x+w/2, y+h, r2);
c.arcTo(x, y+h, x, y+h/2, r3);
c.arcTo(x, y, x+w/2, y, r4);
c.closePath();
c.stroke();
}
Similarly if you want to do different x and y radii it's relatively easy
to pass through to the new arcTo() method. (This isn't widely implemented
yet so I haven't shown an example here.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas arcTo method
On Mon, 20 Aug 2012, Michael Day wrote: The camvas arcTo method generates an arc that touches two tangent lines. The first tangent line is from the last point in the previous subpath to the first point passed to the arcTo method. What happens in this situation: ctx.lineTo(100, 100); ctx.scale(2, 1); ctx.arcTo(100, 100, 100, 200, 100); The current transformation matrix should be used to transform the generated arc, not to transform its control points. The intent is that the whole thing be done in the transformed coordinate space. The spec was rather poorly written, I've made it slightly better (though only minimally so... I'm not really sure how to write the spec to be both clear and accurate). On Tue, 21 Aug 2012, Michael Day wrote: For arcTo, it's much less obvious how the arc should be generated from the three control points, when the first control point is transformed by a different matrix to the last two; in this case you cannot just remember the three points in absolute canvas coordinates, but the specification does not clarify this. Does it work if you just transform all the points and the line? (Yeah, that's still way too vague. I'm not sure how to really specify this in a manner that's both unambiguous and clear. Any suggestions?) On Tue, 21 Aug 2012, Michael Day wrote: You cannot transform the three control points, and then generate the arc. If you do this, you will always get circular arcs, whereas a scale(2, 1) will produce an elliptical arc. You have to generate the arc, then scale it. Yeah, that's why the spec hand-waves to transform the line too... but I agree that that doesn't really work. Do you have any suggestion of how to spec this better? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hardware accelerated canvas
On Sun, 2 Sep 2012, Benoit Jacob wrote: Realistically, there are too many pages that have 2D canvases that are drawn to once and never updated for any solution other than don't lose the data to be adopted. How exactly this is implemented is a quality of implementation issue. With all the current graphics hardware, this means don't use a GL/D3D surface to implement the 2d canvas drawing buffer storage, which implies: don't hardware-accelerate 2d canvases. There are ways to make it work without forgoing acceleration, e.g. taking regular backups of the canvas contents, remembering every instruction that was sent to the canvas, etc. Erik's proposal doesn't worsen the problem in anyway --- it acknowledges a problem that already exists and offers to Web content a way to recover from it. The problem is that there is content that doesn't recover, and assumes the problem doesn't exist. That makes it our problem. On Mon, 3 Sep 2012, Benoit Jacob wrote: Remember this adage from high-performance computing which applies here as well: The fast drives out the slow even if the fast is wrong. Browsers want to have good performance on Canvas games, demos and benchmarks. Users want good performance too. GL/D3D helps a lot there, at the cost of a rather rare -- and practically untestable -- problem with context loss. So browsers are going to use GL/D3D, period. On the desktop, most browsers already do. It seems impossible for the spec to require not using GL/D3D and get obeyed. On Sun, 2 Sep 2012, Glenn Maynard wrote: If the choice becomes follow the spec and don't hardware-accelerate canvas vs. don't follow the spec and get orders of magnitude better performance, I suspect I can guess the choice implementors will make (implementors invited to speak for themselves, of course). This isn't an issue of the spec -- there is existing content that would be affected. On Mon, 3 Sep 2012, Erik Möller wrote: I don't particularly like this idea, but for the sake of having all the options on the table I'll mention it. We could default to the old behaviour and have an opt in for hardware accelerated canvas in which case you would have to respond to said context lost event. That would allow the existing content to keep working as it is without changes. It would be more work for vendors, but it's up to every vendor to decide how to best solve it, either by doing it in software or using the expensive read back alternative in hardware. On Sun, 2 Sep 2012, Rik Cabanier wrote: If there was a callback for context loss and if the user had set it, a browser could throw the entire canvas out and ask for it to be re-rendered if the canvas is shown again. This would even make sense if you don't have a HW accelerated canvas. There would be no backward compatibility issue either. If the user doesn't set the callback, a browser would have to do something reasonable to keep the canvas bitmap around. This is an interesting idea... do other vendors want to provide something like this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hardware accelerated canvas
On Mon, Sep 3, 2012 at 11:11 AM, Ian Hickson i...@hixie.ch wrote: There are ways to make it work without forgoing acceleration, e.g. taking regular backups of the canvas contents, remembering every instruction that was sent to the canvas, etc. As Erik said, taking a snapshot of the canvas is very expensive on some platforms. If you're rendering a game in realtime, you never have a time out where you can tolerate an expensive readback. You can't remember every single instruction sent to the canvas--that would mean keeping every drawImage source alive forever, too. You have to be able to snapshot the backing store and purge the draw list at some point (thus the readback in b) of the original post). I definitely disagree with Benoit's assumption that since WebGL can't come up with anything better, Canvas can't either. 2d canvas and WebGL aren't the same--WebGL has far more state to restore, some of which isn't directly accessible in GLES (eg. depth buffers, IIRC). It's definitely worth evaluating every option before assuming that exposing context loss to developers is really the only possible solution. If the choice becomes follow the spec and don't hardware-accelerate canvas vs. don't follow the spec and get orders of magnitude better performance, I suspect I can guess the choice implementors will make (implementors invited to speak for themselves, of course). This isn't an issue of the spec -- there is existing content that would be affected. Again, there are approaches which can alleviate the common draw once and forget about it cases. For the benefits, I suspect the remaining content breakage would fall well below the threshold people will tolerate, if it came down to it. On Sun, 2 Sep 2012, Rik Cabanier wrote: If there was a callback for context loss and if the user had set it, a browser could throw the entire canvas out and ask for it to be re-rendered if the canvas is shown again. This would even make sense if you don't have a HW accelerated canvas. There would be no backward compatibility issue either. If the user doesn't set the callback, a browser would have to do something reasonable to keep the canvas bitmap around. This is an interesting idea... do other vendors want to provide something like this? Also, would vendors actually be willing to shift existing content to this slower path? This is only a partial solution if implementations don't do that part. -- Glenn Maynard
Re: [whatwg] Hardware accelerated canvas
On Mon, Sep 3, 2012 at 7:21 AM, Benoit Jacob bja...@mozilla.com wrote: - Original Message - What is really meant here by Canvas GPU acceleration? This means use GL/D3D to implement the 2D canvas drawing primitives; but what really matters here, is that this requires using a GL/D3D texture/surface as the primary storage for the 2D canvas drawing buffer. Because of the way that current GPUs work, this entails that the canvas drawing buffer is a /discardable/ resource. Erik's proposal is about dealing with this dire reality. Again, accelerated canvases have been widely used for a year and a half now. It's not realistic to expect the world to go back to non-accelerated by default now. It seems to me that one way or another we have to break something. Canvases drawn into once with no animation loop may go blank with GL-based hardware acceleration, whereas most video games will not function properly without it. I much prefer the former to the latter. I agree that it's unrealistic to go back to non-accelerated canvas. I would like to see a provision for handling lost contexts along the lines of Rick's proposal, perhaps with some underlying integration with requestAnimationFrame() so application developers don't have to get directly involved. HTML is a living specification and I believe developers would rather have occasional breaks with backwards compatibility instead of severely reduced performance. david Benoit
Re: [whatwg] Hardware accelerated canvas
On Mon, Sep 3, 2012 at 10:31 AM, David Geary david.mark.ge...@gmail.comwrote: On Mon, Sep 3, 2012 at 7:21 AM, Benoit Jacob bja...@mozilla.com wrote: - Original Message - What is really meant here by Canvas GPU acceleration? This means use GL/D3D to implement the 2D canvas drawing primitives; but what really matters here, is that this requires using a GL/D3D texture/surface as the primary storage for the 2D canvas drawing buffer. Because of the way that current GPUs work, this entails that the canvas drawing buffer is a /discardable/ resource. Erik's proposal is about dealing with this dire reality. Again, accelerated canvases have been widely used for a year and a half now. It's not realistic to expect the world to go back to non-accelerated by default now. It seems to me that one way or another we have to break something. Canvases drawn into once with no animation loop may go blank with GL-based hardware acceleration, whereas most video games will not function properly without it. I much prefer the former to the latter. No, we can't break the current implementation. It's perfectly reasonable for an author to draw into a canvas once and expect that the browser will manage it properly. I agree that it's unrealistic to go back to non-accelerated canvas. I would like to see a provision for handling lost contexts along the lines of Rick's proposal, perhaps with some underlying integration with requestAnimationFrame() so application developers don't have to get directly involved. I'm unsure why you bring up requestAnimationFrame(). Can you elaborate? HTML is a living specification and I believe developers would rather have occasional breaks with backwards compatibility instead of severely reduced performance. david Benoit
Re: [whatwg] Hardware accelerated canvas
I apologize in advance, as this is slightly off-topic. I've been unsuccessfully looking for info on how Canvas hardware acceleration actually works and haven't found much. Would anyone have pointers? Thanks. --tobie
[whatwg] Hardware accelerated Canvas
Hi, Hardware accelerated Canvas is a necessity. If it is not done than HTML5 will never be able to compete with native platforms. Most applications need 2D rendering for UI but application developers these days demand at par performance with native counterparts. WebGL is not a good option for 2D only stuff since its relatively complicated and still not fully supported on all platforms. Even open source libraries like Three.js are not fully documented. So Canvas remains the only viable option for application developers for most UI related stuff. Yes many web developers do not know about rendering loops but with requestAnimationFrame this will change. This change has to happen as users are demanding more complex and beautiful UI everyday thanks to their use of iOS and other mobile apps. Saurabh Jain Director, SKJ Technologies Private Ltd http://www.skjapp.com/ Founder, OpenClass http://www.skjapp.com/openclass (Community of web and mobile app developers) http://www.facebook.com/openpad Author : Mobile Phone Programming using Java ME (J2ME) http://library.skjworld.com/mobile-technology/java/java-me Twitter : http://twitter.com/skjsaurabh
