- From: Dirk Schulze <dschulze@adobe.com>
- Date: Wed, 12 Mar 2014 09:38:19 +0000
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Edward O'Connor <eoconnor@apple.com>
On Mar 12, 2014, at 12:13 AM, Rik Cabanier <cabanier@gmail.com> wrote: > On Tue, Mar 11, 2014 at 10:03 AM, Edward O'Connor <eoconnor@apple.com>wrote: > >> Hi Rik, >> >> You wrote: >> >>> Currently, the specification states that if you create a region and >>> then create another region that completely covers region, the first >>> region is removed from the hit region list [1] >>> >>> This is a complex operation that involves either drawing the regions >>> to a bitmaps and counting pixels, or path intersection. It is also >>> unintuitive because an author might expect that he could remove the >>> second region and still have the first region active. >>> >>> What was the reason that this was added to the spec? >> >> The model the spec uses for hit regions is that you have two bitmaps--one >> for the canvas surface, and the other is used to track which hit region >> the pixels of the canvas surface are in. See this thread from 2012: >> >> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 > > > Thanks! > It looks like that thread never came to a conclusion. > > The arguments against using a bitmap presentation still stand: > - it will be too expensive to keep an actual copy of the canvas pixels in > memory to do hit testing > - if you have to mimic the behavior with paths, you need access to > expensive/difficult path manipulation algorithms > > Hit regions should be redesigned so they work on the path geometry as > opposed to pixels. We already have the necessary code to do hit testing on > paths (see isPointInPath) In SVG we tried to avoid having hit testing based on pixel values obviously for performance reasons. Greetings, Dirk
Received on Wednesday, 12 March 2014 09:39:12 UTC