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
