On 14 July 2011 04:32, Greg Brown <gk_br...@verizon.net> wrote: >> It just seems cleaner to prepare the data first, and then let >> ImageView simply show whatever it has been given. Much the same as >> when populating a ListView, TableView or TreeView for example. > > The difference is that the renderer would be modifying the data, rather than > the application. That isn't good.
No, I am not suggesting the renderer do anything other than render, and certainly not modify any data. In fact the renderer wouldn't even know that the 'clipped' image was in any way different to any other image. For that matter, neither would ImageView or anything else that uses Images, as it is none of their concern where the data originally came from, or comes from now. They just need to know how to deal with it once they are given it. Continuing the comparison with ListView - I can use a base List<Widget> as the 'listData' for one ListView, and then create a 2nd List<Widget> (which is backed by the other list) and use as the 'listData' for another ListView. (The old FilteredList class would be a perfect example of one list backed by another) Similarly, offsets & clip bounds would be handled by a lightweight Image (the equivalient of the FilteredList above). That Image would be backed by the 'source image' and just would paint the relevant part of that source image when its own paint method was called. It could be considered similar to how the consumer of a java.io.InputStream just deals with the data it receives, without knowledge of any processing that may have occurred beforehand and transformed the data in some way. Image = java.io.InputStream ClippedImage = java.io.FilterInputStream
