On Fri, Jul 6, 2012 at 5:40 PM, Dean Jackson wrote:
>
> On 07/07/2012, at 10:11 AM, Charles Pritchard wrote:
>
> >> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor
> wrote:
> >>> As things currently stand in the spec, implementations basically need
> to
> >>> keep N+1 bitmaps per canvas, where
On Jul 5, 2012, at 11:28 PM, Tab Atkins Jr. wrote:
> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor wrote:
>> As things currently stand in the spec, implementations basically need to
>> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
>> doubt any implementors would be enth
On 07/07/2012, at 10:11 AM, Charles Pritchard wrote:
>> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor wrote:
>>> As things currently stand in the spec, implementations basically need to
>>> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
>>> doubt any implementors would b
On Jul 5, 2012, at 11:28 PM, "Tab Atkins Jr." wrote:
> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor wrote:
>> As things currently stand in the spec, implementations basically need to
>> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
>> doubt any implementors would be ent
On Thu, Jul 5, 2012 at 11:28 PM, Tab Atkins Jr. wrote:
> On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor
> wrote:
> > As things currently stand in the spec, implementations basically need to
> > keep N+1 bitmaps per canvas, where N is the number of hit regions. I
> > doubt any implementors would
On Thu, 5 Jul 2012, Charles Pritchard wrote:
> On Jul 5, 2012, at 10:06 PM, Ian Hickson wrote:
> >>
> >> I think its up to the author to manage their set of paths
> >> appropriately, independently from the drawing operations.
> >
> > Having the drawing mechanism work in a tightly integrated fas
On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor wrote:
> As things currently stand in the spec, implementations basically need to
> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
> doubt any implementors would be enthusiastic to implement hit regions
> like this. From a WebKi
On Jul 5, 2012, at 10:06 PM, Ian Hickson wrote:
>> I think its up to the author to manage their set of paths appropriately,
>> independently from the drawing operations.
>
> Having the drawing mechanism work in a tightly integrated fashion with the
> region code IMHO helps authors avoid bugs.
On Thu, 5 Jul 2012, Simon Fraser wrote:
> On Jul 5, 2012, at 2:25 PM, Ian Hickson wrote:
> > On Thu, 5 Jul 2012, Edward O'Connor wrote:
> >>
> >> As things currently stand in the spec, implementations basically need
> >> to keep N+1 bitmaps per canvas, where N is the number of hit regions.
> >>
On Jul 5, 2012, at 2:25 PM, Ian Hickson wrote:
> On Thu, 5 Jul 2012, Edward O'Connor wrote:
>>
>> As things currently stand in the spec, implementations basically need to
>> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
>> doubt any implementors would be enthusiastic to
On Thu, 5 Jul 2012, Edward O'Connor wrote:
>
> As things currently stand in the spec, implementations basically need to
> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
> doubt any implementors would be enthusiastic to implement hit regions
> like this. From a WebKit persp
On Jul 5, 2012, at 1:05 PM, Edward O'Connor wrote:
> Hi,
>
> As things currently stand in the spec, implementations basically need to
> keep N+1 bitmaps per canvas, where N is the number of hit regions. I
> doubt any implementors would be enthusiastic to implement hit regions
> like this. From
Hi,
As things currently stand in the spec, implementations basically need to
keep N+1 bitmaps per canvas, where N is the number of hit regions. I
doubt any implementors would be enthusiastic to implement hit regions
like this. From a WebKit perspective, we'd much prefer keeping a Path
for each hit
13 matches
Mail list logo
