W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] hit regions: clearing of regions

From: Dirk Schulze <dschulze@adobe.com>
Date: Wed, 12 Mar 2014 09:38:19 +0000
To: Rik Cabanier <cabanier@gmail.com>
Message-ID: <73AF577E-BF27-4F35-8754-4C83D1165B17@adobe.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.

Received on Wednesday, 12 March 2014 09:39:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC