Yeah. See my first reply to Edvin.
On 14 July 2011 05:28, Greg Brown <gk_br...@verizon.net> wrote: > Ah, I see - like a decorator. > > > On Jul 13, 2011, at 5:56 PM, Chris Bartlett wrote: > >> 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 > >
