W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2008

[whatwg] More random comments on the putImageData definition

From: Oliver Hunt <oliver@apple.com>
Date: Fri, 25 Jan 2008 12:00:41 -0800
Message-ID: <B83F86C9-36A8-4BC5-9CA9-451D600CECF8@apple.com>

On Jan 25, 2008, at 6:53 AM, Adam Roben wrote:

>
> On Jan 25, 2008, at 6:56 AM, Oliver Hunt wrote:
>
>> With the current model for putImageData there is no way for them to  
>> specify a dirty rect, which means their only option is to update  
>> the entire display -- they have to copy the entire buffer.
<snip>
>
> I think it would be less confusing for the repaint region to always  
> have its origin at (dx, dy). This would be more similar to Windows'  
> BitBlt API. Something like:
>
> void putImageData(in ImageData imageData, in float destX, in float  
> destY, in float srcX, in float srcY, in float width, in float height)
>
> destX and destY are in canvas coordinates
> srcX and srcY are in ImageData coordinates
>
> The data from the ImageData in the rectangle specified by (srcX,  
> srcY, width, height) is then painted into the canvas in the  
> rectangle (destX, destY, width, height).
The problem in that case is that it would not be backwards compatible  
-- eg.
puImageData(data, destx, desty, srcx, srcy, width, height)

If the UA supports dirty region mapping then it would effectively be  
mapping (0,0) on the ImageData to (destx - srcx, desty - srcy),  
whereas a UA that does not support dirty regions would be mapping  
(0,0) to (destx,desty) and so wouldbe broken.  That's why i said the  
dirty rect should be relative to the imagedata origin, i also feel it  
makes more sense to say "this area of the imagedata is the interesting  
bit" rather than "once you've blitted, this area of the *canvas* will  
be interesting"

--Oliver

>
>
> -Adam
>
Received on Friday, 25 January 2008 12:00:41 UTC

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