Just thinking out loadly;<br><br>Wouldn't it be easier to implement that cache at the driver level, just by composing the raster in a temp image buffer and feed that image in the subsequent IReadBlock calls? I think we should also think about the non regular and overlapping blocks which should also be covered by the implementation here.<br>
<br>Best regards,<br><br>Tamas<br><br><br><br><br><div class="gmail_quote">2009/8/7 Tamas Szekeres <span dir="ltr"><<a href="mailto:szekerest@gmail.com">szekerest@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="im">2009/8/7 Jorge Arévalo <span dir="ltr"><<a href="mailto:jorge.arevalo@gmail.com" target="_blank">jorge.arevalo@gmail.com</a>></span><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br><div class="im">
> One issue with this concept would be related to the limited memory size of<br>
> the particular machine, it may be more reasonable to copy the retrieved<br>
> blocks directly onto the output buffer if possible. In this case you cannot<br>
> much rely on the base RasterIO implementation.<br>
<br>
</div></div><div class="im">So, you suggest to copy the block data into the buffer without calling<br>
base implementation of IRasterIO, do you? This implies take care of<br>
the endianess and pixel size "by hand".<br>
</div></blockquote><div><br>And many more... I agree this wouldn't be that straightforward. Populating the block buffer would be much easier.<br><br>Best regards,<br><br>Tamas<br></div></div><br>
</blockquote></div><br>