Re: Integration of HTM

On Feb 8, 2010, at 5:18 PM, Robert O'Callahan wrote:

> On Tue, Feb 9, 2010 at 1:25 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> I am concerned however about overlaying the canvas with 0.01 opacity divs. I expect this will have a negative impact on canvas rendering performance, especially if there are significant animations. Because even though 0.01 opacity likely won't draw anything visible, the browser still has to render and composite the content on top of the canvas.
>  
> In the future we can probably expect most browsers to use graphics hardware in a way that makes the compositing cheap/free.

Making it cheap/free in speed would probably increase the cost in memory use. The overlays would need their own backing store bitmap (at least for the obvious ways to do this).

> However, opacity:epsilon does seem rather ugly. Wouldn't opacity:0 work here? In Gecko at least that would optimize away almost all rendering (while still catching events).

WebKit could probably better optimize opacity: 0 or visibility: hidden. I suspect the reason for opacity: epsilon is that opacity: 0 or visibility: hidden would cause the content to be hidden from assistive technologies in at least some browsers.

> 
> I am also wondering how this technique can be extended to control target areas that are not rectangles.
> 
> I'm wondering that too. I wonder if it would make sense to add some kind of canvas API that lets you associate an element with the current path. Mmm, sounds like image maps :-).

You could use <area>, although I don't believe those can be arbitrary shapes. Letting JS code do its own hit testing against the canvas and dispatch to a DOM element would work - I'm not sure how essential it is to this technique that the accessibility tree is on top of the canvas instead of below.

Regards,
Maciej