You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Chris Bartlett <cb...@gmail.com> on 2011/07/13 16:25:36 UTC
Re: ImageView support for sprite/offset
Edvin,
I think this kind of discussion is probably better suited to the dev
mailing list (dev@pivot.apache.org).
This reply is being sent to both user and dev lists. I will write a
proper reply to the dev list in a moment.
For anyone wishing to follow this thread, the info for signing up to
all the mailing lists can be found here.
http://pivot.apache.org/lists.html
Chris
On 13 July 2011 21:15, SYSE | Edvin <es...@syse.no> wrote:
> More and more often I come across existing web-graphics that needs to be
> reused in desktop-applications. Webdesigners are gradually shifting towards
> creating a sprite containing multiple images and using css to choose which
> image to show.
>
> I would like to propose a small change to ImageView to support this
> behavior, so that one can easier reuse existing web-graphics in
> desktop-applications. Provided is a patch that shows what I mean.
>
> Here is an example of it's usage. Take a look at the following picture:
>
> http://askjems.no/files/gfx/viewmodes_sprite.png
>
> Showing the first "icon" in this image can be done by restricting the
> maximum height to the height of each "icon":
>
> int iconHeight = 27;
> imageView.setPreferredHeight(iconHeight);
>
> My patch will allow you to do this to show the second "icon":
>
> imageView.getStyles().put("offsetY", iconHeight);
>
> Third icon:
>
> imageView.getStyles().put("offsetY", iconHeight * 2);
>
> offsetX is also supported, for multi column sprites. Does that make
> sense/look valuable?
>
> -- Edvin
>
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
I'm certainly no expert on this, but I think manageability is a key issue.
Maintaining & distributing a single image asset is easier than doing
so for potentially hundreds of small icons. This technique seems to
fit well when there is a grid of equally sized 'icons', and is
something I saw in game development aeons ago.
On 13 July 2011 21:45, Greg Brown <gk...@verizon.net> wrote:
> This is an interesting question. Why might a web designer want to use this technique versus discrete images?
>
> On Jul 13, 2011, at 10:37 AM, Chris Bartlett wrote:
>
>> (Forwarded from the user list)
>>
>> Edvin,
>>
>> I can definitely see the value of being able to target a smaller
>> 'chunk' of a larger image, (and have seen entire icon sets being
>> distributed in a single 'contact sheet') but my gut reaction is that
>> ImageView is not the right place for it.
>>
>> ImageView obviouly displays Image objects.
>> http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/media/Image.html
>>
>> How about moving the logic into a custom Image class instead? Perhaps
>> one that just 'decorates' other Images.
>>
>> ImageChunk imageChunk = new ImageChunk(someOtherImage);
>> imageChunk.setOffset(100, 100);
>> imageChunk.setSize(32, 32);
>> ImageView imageView = new ImageView(imageChunk);
>>
>> Chris
>>
>>> On 13 July 2011 21:15, SYSE | Edvin <es...@syse.no> wrote:
>>>> More and more often I come across existing web-graphics that needs to be
>>>> reused in desktop-applications. Webdesigners are gradually shifting towards
>>>> creating a sprite containing multiple images and using css to choose which
>>>> image to show.
>>>>
>>>> I would like to propose a small change to ImageView to support this
>>>> behavior, so that one can easier reuse existing web-graphics in
>>>> desktop-applications. Provided is a patch that shows what I mean.
>>>>
>>>> Here is an example of it's usage. Take a look at the following picture:
>>>>
>>>> http://askjems.no/files/gfx/viewmodes_sprite.png
>>>>
>>>> Showing the first "icon" in this image can be done by restricting the
>>>> maximum height to the height of each "icon":
>>>>
>>>> int iconHeight = 27;
>>>> imageView.setPreferredHeight(iconHeight);
>>>>
>>>> My patch will allow you to do this to show the second "icon":
>>>>
>>>> imageView.getStyles().put("offsetY", iconHeight);
>>>>
>>>> Third icon:
>>>>
>>>> imageView.getStyles().put("offsetY", iconHeight * 2);
>>>>
>>>> offsetX is also supported, for multi column sprites. Does that make
>>>> sense/look valuable?
>>>>
>>>> -- Edvin
>>>>
>>>
>
>
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
> If it goes in Picture, will it still be possible somehow to apply styles to an ImageView and make it use the desired offset, or will you have to do this programatically then?
I imagine you'd have to do it programmatically.
How does it work in CSS?
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
This is what I was getting at when talking about a 'lightweight Image
backed by another Image'. It is just a quick proof of concept, but
seems to work fine.
Not sure it it will turn out to be useful for this discussion, but
somebody on the mailing list might have a use for it.
The script application looks for a local copy of the icon file that
Edvin linked to earlier, but doesn't include it. I hope that is OK,
Edvin?
(https://www.syse.no/files/gfx-dark/icons_64x64_cp.png)
Place it in the 'sprite.offset' package directory and it should be
picked up. Otherwise change the name & location in the BXML file as
required.
It should be possible to substitute any other evenly spaced vertical
list of icons fairly easily. Just adjust the 'size' and 'offset'
variables at the top of the BXML file, and any bounds settings for the
ClippedImage instances.
You can see that an image is only loaded once, and then reused in
multiple ImageViews via ClippedImage objects.
It is also possible to chain them together like other 'decorators', so
you can start with one image, create a 2nd ClippedImage representing
part of the 1st, and then a 3rd ClippedImage representing part of the
2nd. This is demonstrated with the Slider in the last column of the
first TabPane tab.
I didn't make any attempts to address BXML friendliness for renderers
and the like, but what was discussed towards the end of the thread
yesterday could be applied to this too.
Chris
On 14 July 2011 05:35, Chris Bartlett <cb...@gmail.com> wrote:
> Yeah. See my first reply to Edvin.
>
> On 14 July 2011 05:28, Greg Brown <gk...@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...@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
>>
>>
>
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
Yeah. See my first reply to Edvin.
On 14 July 2011 05:28, Greg Brown <gk...@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...@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
>
>
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
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...@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
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 14 July 2011 04:32, Greg Brown <gk...@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
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
> Something just doesn't sit right with me about passing data to
> ImageView, and then telling it to only show part of it.
I think it makes sense. And it does seem consistent with the CSS usage.
> 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.
> I suppose it could be argued that the ImageView is just 'rendering'
> its data in a different way
I think this is a good analogy.
> What if a ListItem (or similar source of content) should be displayed
> with different icons depending on whether or not it was selected or
> disabled?
I'd suggest adding a disabledIcon property to ListItem and adding support for it to ListViewItemRenderer.
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 14 July 2011 03:23, Greg Brown <gk...@verizon.net> wrote:
>> The same syntax could also be used to support a clip area on an Image/Picture.
>> Instead of the iconBounds data being passed on to an ImageView, it
>> would instead be passed on the Image/Picture that ButtonData uses
>> internally.
>
> True, but that's kind of sketchy. It would actually be modifying the button's data, which renderers aren't really supposed to do. The renderer "owns" the image view, so it is OK to modify that.
No, not modifying it, just specifying the bounds within the larger
image that should be exposed as a smaller image. Much the same as a
Panorama showing an image doesn't modify the larger image, but just
exposes part of it.
I was thinking of a lightweight ClippedImage for want of a better
name, that would just wrap/decorate another Image.
// Load an image resource
Image sourceImage = Image.load(...);
// Create a new image that shares another Image's data
// At this point it would just be a duplicate of the source image, but
sharing its BufferedImage or whatever is used internally.
ClippedImage image = new ClippedImage(sourceImage);
// Now would its size would be determined by the supplied bounds, and
it would only show the appropriate section of the source image (not
actually create a copy of the source and clip it)
image.setClipBounds(bounds);
// Or even simply this ....
Image sourceImage = Image.load(...);
// Returns a new Image sharing the actual data of sourceImage
image = sourceImage.getImage(bounds);
Something just doesn't sit right with me about passing data to
ImageView, and then telling it to only show part of it. Perhaps if it
there were frequent context switches, such as when creating an
animation from parts of an image (think animated GIF).
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. You
figure out what you want it to display and then provide it to the
Component. You can't directly tell a ListView to only show the
widgets with a sale price of > $10. You do that by manipulating the
list that ListView uses.
Are there other Components that are managed differently to ListView,
TableView & TreeView? Containers do to a certain extent, but that is
part of their purpose.
I suppose it could be argued that the ImageView is just 'rendering'
its data in a different way, but then why not introduce an
ImageViewRenderer interface? (Not that I think this is necessary or
desirable)
One other thing popped into my head, but probably doesn't need any
special consideration.
What if a ListItem (or similar source of content) should be displayed
with different icons depending on whether or not it was selected or
disabled?
The current solution would probably involve a custom renderer which
knows about the multiple icons (or how to read them from a ListItem
that supports multiple icons) and places them into the renderer's
ImageView accordingly. I suppose the same would be true with this
proposal, only that the ImageView would have its clip bounds adjusted
- either instead of, or possibly even in addition to changing the
source image.
Chris
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
Hmm. I just re-read this and am not 100% sure we are talking about
the same things, so bear that in mind when reading my reply.
On 14 July 2011 03:23, Greg Brown <gk...@verizon.net> wrote:
>> The same syntax could also be used to support a clip area on an Image/Picture.
>> Instead of the iconBounds data being passed on to an ImageView, it
>> would instead be passed on the Image/Picture that ButtonData uses
>> internally.
>
> True, but that's kind of sketchy. It would actually be modifying the button's data, which renderers aren't really supposed to do. The renderer "owns" the image view, so it is OK to modify that.
>
>
>
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
> The same syntax could also be used to support a clip area on an Image/Picture.
> Instead of the iconBounds data being passed on to an ImageView, it
> would instead be passed on the Image/Picture that ButtonData uses
> internally.
True, but that's kind of sketchy. It would actually be modifying the button's data, which renderers aren't really supposed to do. The renderer "owns" the image view, so it is OK to modify that.
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 14 July 2011 02:52, SYSE | Edvin <es...@syse.no> wrote:
> Den 13.07.2011 21:45, skrev Greg Brown:
>>
>> If the clip area is specified on ImageView, I think it would be possible
>> to support the renderer case by just adding another property to the content
>> classes that specifies the clip area. The renderer would just pass this
>> along to the ImageView:
>>
>> <ButtonData text="foo" icon="@bar.png" iconBounds="{x:0, y:0 ,width:32,
>> height:32}"/>
>>
>> If not specified (null), the bounds would default to the image size.
>
> That's VERY nice :))
>
The same syntax could also be used to support a clip area on an Image/Picture.
Instead of the iconBounds data being passed on to an ImageView, it
would instead be passed on the Image/Picture that ButtonData uses
internally.
So this would be ...
<ButtonData text="foo" icon="@bar.png" iconBounds="{x:0, y:0
,width:32, height:32}"/>
... the equivalent of this
<ButtonData text="foo">
<icon>
<Image image="@bar.png" iconBounds="{x:0, y:0 ,width:32, height:32}"/>
</icon>
<ButtonData>
I'm just thinking about the use of ImageViews and Images/Pictures and
if there are cases where this same functionality would be useful for
an Image/Picture, but when an ImageView is not involved.
A quick search through the source seems to suggest that
Images/Pictures are rarely used when an ImageView is not involved, so
it is probably not a big deal.
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 21:45, skrev Greg Brown:
> If the clip area is specified on ImageView, I think it would be possible to support the renderer case by just adding another property to the content classes that specifies the clip area. The renderer would just pass this along to the ImageView:
>
> <ButtonData text="foo" icon="@bar.png" iconBounds="{x:0, y:0 ,width:32, height:32}"/>
>
> If not specified (null), the bounds would default to the image size.
That's VERY nice :))
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
If the clip area is specified on ImageView, I think it would be possible to support the renderer case by just adding another property to the content classes that specifies the clip area. The renderer would just pass this along to the ImageView:
<ButtonData text="foo" icon="@bar.png" iconBounds="{x:0, y:0 ,width:32, height:32}"/>
If not specified (null), the bounds would default to the image size.
On Jul 13, 2011, at 3:36 PM, Chris Bartlett wrote:
> I imagine that any solution would have bean type properties to allow
> the configuration of the offset and size, either directly in java (or
> your JVM language of choice) or in BXML. Is that what you mean my
> programmatically?
>
> Something like
> imageView.setImage(sourceImage);
> imageView.setClipBounds(bounds);
>
> or
> Picture picture = new Picture(sourceImage);
> picture.setClipBounds(bounds);
>
> or in BXML
> <ImageView image="@sourceImage.png" clipBounds="{x:100, y:100,
> width:32, height:32}" />
>
> On 14 July 2011 02:18, SYSE | Edvin <es...@syse.no> wrote:
>> Den 13.07.2011 21:14, skrev Chris Bartlett:
>>>
>>> On 14 July 2011 01:41, Greg Brown<gk...@verizon.net> wrote:
>>>>
>>>> There's still an open question about where this really belongs: ImageView
>>>> or Picture. If the feature is likely to be used for Drawings as well, or if
>>>> you might want to display different cells from the same sheet in multiple
>>>> ImageViews, then it clearly should go in ImageView. Otherwise, it probably
>>>> belongs in Picture.
>>>
>>> ImageViews are used heavily in the provided renderers, so that should
>>> be taken into consideration too. It would be a shame to introduce such
>>> a feature and not have an easy way to extract icons from a larger
>>> source image for use in renderers. Although, it would obviously be
>>> possible to write a custom renderer or extend the provided ones.
>>
>> If it goes in Picture, will it still be possible somehow to apply styles to
>> an ImageView and make it use the desired offset, or will you have to do this
>> programatically then?
>>
>> -- Edvin
>>
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
> In CSS, you control the background-position property, ie. using the image as a background in another container.
OK, so that is analogous to specifying it on ImageView.
> CSS also has support for:
>
> img {
> clip:rect(0px,60px,200px,0px);
> }
And that is analogous to specifying it on Picture.
To me, it seems like ImageView is the best place for it.
G
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 21:42, skrev Greg Brown:
> If it is added to ImageView, it should be pretty easy to use in markup. If it is added to Picture, it won't be as easy since Pictures aren't generally used directly in markup.
That's a major one in my opinion.
> How does it work in CSS?
In CSS, you control the background-position property, ie. using the
image as a background in another container. CSS also has support for:
img {
clip:rect(0px,60px,200px,0px);
}
... but I haven't seen anyone using it, they all go with the
background-position solution.
-- Edvin
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
If it is added to ImageView, it should be pretty easy to use in markup. If it is added to Picture, it won't be as easy since Pictures aren't generally used directly in markup.
On Jul 13, 2011, at 3:36 PM, Chris Bartlett wrote:
> I imagine that any solution would have bean type properties to allow
> the configuration of the offset and size, either directly in java (or
> your JVM language of choice) or in BXML. Is that what you mean my
> programmatically?
>
> Something like
> imageView.setImage(sourceImage);
> imageView.setClipBounds(bounds);
>
> or
> Picture picture = new Picture(sourceImage);
> picture.setClipBounds(bounds);
>
> or in BXML
> <ImageView image="@sourceImage.png" clipBounds="{x:100, y:100,
> width:32, height:32}" />
>
> On 14 July 2011 02:18, SYSE | Edvin <es...@syse.no> wrote:
>> Den 13.07.2011 21:14, skrev Chris Bartlett:
>>>
>>> On 14 July 2011 01:41, Greg Brown<gk...@verizon.net> wrote:
>>>>
>>>> There's still an open question about where this really belongs: ImageView
>>>> or Picture. If the feature is likely to be used for Drawings as well, or if
>>>> you might want to display different cells from the same sheet in multiple
>>>> ImageViews, then it clearly should go in ImageView. Otherwise, it probably
>>>> belongs in Picture.
>>>
>>> ImageViews are used heavily in the provided renderers, so that should
>>> be taken into consideration too. It would be a shame to introduce such
>>> a feature and not have an easy way to extract icons from a larger
>>> source image for use in renderers. Although, it would obviously be
>>> possible to write a custom renderer or extend the provided ones.
>>
>> If it goes in Picture, will it still be possible somehow to apply styles to
>> an ImageView and make it use the desired offset, or will you have to do this
>> programatically then?
>>
>> -- Edvin
>>
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
I imagine that any solution would have bean type properties to allow
the configuration of the offset and size, either directly in java (or
your JVM language of choice) or in BXML. Is that what you mean my
programmatically?
Something like
imageView.setImage(sourceImage);
imageView.setClipBounds(bounds);
or
Picture picture = new Picture(sourceImage);
picture.setClipBounds(bounds);
or in BXML
<ImageView image="@sourceImage.png" clipBounds="{x:100, y:100,
width:32, height:32}" />
On 14 July 2011 02:18, SYSE | Edvin <es...@syse.no> wrote:
> Den 13.07.2011 21:14, skrev Chris Bartlett:
>>
>> On 14 July 2011 01:41, Greg Brown<gk...@verizon.net> wrote:
>>>
>>> There's still an open question about where this really belongs: ImageView
>>> or Picture. If the feature is likely to be used for Drawings as well, or if
>>> you might want to display different cells from the same sheet in multiple
>>> ImageViews, then it clearly should go in ImageView. Otherwise, it probably
>>> belongs in Picture.
>>
>> ImageViews are used heavily in the provided renderers, so that should
>> be taken into consideration too. It would be a shame to introduce such
>> a feature and not have an easy way to extract icons from a larger
>> source image for use in renderers. Although, it would obviously be
>> possible to write a custom renderer or extend the provided ones.
>
> If it goes in Picture, will it still be possible somehow to apply styles to
> an ImageView and make it use the desired offset, or will you have to do this
> programatically then?
>
> -- Edvin
>
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 21:14, skrev Chris Bartlett:
> On 14 July 2011 01:41, Greg Brown<gk...@verizon.net> wrote:
>> There's still an open question about where this really belongs: ImageView or Picture. If the feature is likely to be used for Drawings as well, or if you might want to display different cells from the same sheet in multiple ImageViews, then it clearly should go in ImageView. Otherwise, it probably belongs in Picture.
>
> ImageViews are used heavily in the provided renderers, so that should
> be taken into consideration too. It would be a shame to introduce such
> a feature and not have an easy way to extract icons from a larger
> source image for use in renderers. Although, it would obviously be
> possible to write a custom renderer or extend the provided ones.
If it goes in Picture, will it still be possible somehow to apply styles
to an ImageView and make it use the desired offset, or will you have to
do this programatically then?
-- Edvin
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 14 July 2011 01:41, Greg Brown <gk...@verizon.net> wrote:
> There's still an open question about where this really belongs: ImageView or Picture. If the feature is likely to be used for Drawings as well, or if you might want to display different cells from the same sheet in multiple ImageViews, then it clearly should go in ImageView. Otherwise, it probably belongs in Picture.
ImageViews are used heavily in the provided renderers, so that should
be taken into consideration too. It would be a shame to introduce such
a feature and not have an easy way to extract icons from a larger
source image for use in renderers. Although, it would obviously be
possible to write a custom renderer or extend the provided ones.
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
> Yes. You can reuse existing sprite-graphics, and the tradeoff is memory consumption. Even with a bunch of images like the one above, I will only use a few houndred kilobytes at worst, and my Pivot app will still use far less memory than Firefox uses to display '<h1>Hello world</h1>'.
True. :-)
> Developers trade convenience for speed and memory all the time. After all, we are using ORM's right? :)
Well, maybe you are. ;-)
> It would be nice to see this very small optimization make it into Pivot - if so, where should it go? :) One last shout out for my initial suggestion - it is minimal, doesn't introduce any new classes, and it's very easy to understand and use, directly via styles.
There's still an open question about where this really belongs: ImageView or Picture. If the feature is likely to be used for Drawings as well, or if you might want to display different cells from the same sheet in multiple ImageViews, then it clearly should go in ImageView. Otherwise, it probably belongs in Picture.
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 17:54, skrev Greg Brown:
> True, but if the sprite image contains a number of images that are not needed at any given time, then it is consuming more memory than necessary. For example, this graphic contains scaled versions of the various icons:
>
> https://www.syse.no/files/gfx-dark/tornado_icons_sprite_dark.png
>
> It's pretty unlikely that more than a single version of each icon would be used at any given time in an application. In that case, the application is almost undoubtedly better off extracting icons of the required size rather than keeping the entire sheet in memory.
>
> I still see this primarily as a performance optimization. It's great if you want to lower your connectivity requirements or avoid the hit of loading an image when it is actually needed, but otherwise discrete images are probably the better option. I think the primary use case for this, as Edvin pointed out, is the ability to re-use existing web graphics rather than requiring the designer to cut them up. Developers will just need to be aware of the implications of using this feature (i.e. larger memory footprint).
Yes. You can reuse existing sprite-graphics, and the tradeoff is memory
consumption. Even with a bunch of images like the one above, I will only
use a few houndred kilobytes at worst, and my Pivot app will still use
far less memory than Firefox uses to display '<h1>Hello world</h1>'.
Developers trade convenience for speed and memory all the time. After
all, we are using ORM's right? :) There is also an economical side to
this, not bothering the designers more than necessary.
It would be nice to see this very small optimization make it into Pivot
- if so, where should it go? :) One last shout out for my initial
suggestion - it is minimal, doesn't introduce any new classes, and it's
very easy to understand and use, directly via styles.
-- Edvin
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
OK, got you.
Another side of the argument would be that it is the responsibility of
the developer/team to manage the assets used by an application, and
divide up the source image into multiple images for reuse, as that is
what Pivot supports. In many cases the image assets will be bespoke,
so the design team would have the ability to produce the final images
in whatever format, size etc was requested.
Don't get me wrong - I like this idea as it offers flexibility along
with the potential to reduce duplication of assets and processing
effort that might otherwise be required to split one image into many.
On 13 July 2011 23:16, Greg Brown <gk...@verizon.net> wrote:
> Right. I'm just saying that, in the absence of Edvin's requirement to re-use existing sprite graphics, I'm not sure I'd advocate supporting this feature. A typical Pivot app doesn't require the HTTP connectivity optimization, nor does it require this feature in order to load multiple images into memory for possible future use.
>
> On Jul 13, 2011, at 12:09 PM, Chris Bartlett wrote:
>
>> On 13 July 2011 22:54, Greg Brown <gk...@verizon.net> wrote:
>>> True, but if the sprite image contains a number of images that are not needed at any given time, then it is consuming more memory than necessary.
>>
>> Yes, of course an image, or by definition anything with superfluous
>> data has overhead. My point was that it can't be assumed that the
>> image will contain anything other than the minimum required to meet
>> its purpose.
>
>
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
Right. I'm just saying that, in the absence of Edvin's requirement to re-use existing sprite graphics, I'm not sure I'd advocate supporting this feature. A typical Pivot app doesn't require the HTTP connectivity optimization, nor does it require this feature in order to load multiple images into memory for possible future use.
On Jul 13, 2011, at 12:09 PM, Chris Bartlett wrote:
> On 13 July 2011 22:54, Greg Brown <gk...@verizon.net> wrote:
>> True, but if the sprite image contains a number of images that are not needed at any given time, then it is consuming more memory than necessary.
>
> Yes, of course an image, or by definition anything with superfluous
> data has overhead. My point was that it can't be assumed that the
> image will contain anything other than the minimum required to meet
> its purpose.
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 13 July 2011 22:54, Greg Brown <gk...@verizon.net> wrote:
> True, but if the sprite image contains a number of images that are not needed at any given time, then it is consuming more memory than necessary.
Yes, of course an image, or by definition anything with superfluous
data has overhead. My point was that it can't be assumed that the
image will contain anything other than the minimum required to meet
its purpose.
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
> A single image might contain all icons required for a specific piece
> of functionality. They might all be required up front, or at some
> point in the app's lifecycle, so it is not necessarily true that more
> is being held in memory than is required.
True, but if the sprite image contains a number of images that are not needed at any given time, then it is consuming more memory than necessary. For example, this graphic contains scaled versions of the various icons:
https://www.syse.no/files/gfx-dark/tornado_icons_sprite_dark.png
It's pretty unlikely that more than a single version of each icon would be used at any given time in an application. In that case, the application is almost undoubtedly better off extracting icons of the required size rather than keeping the entire sheet in memory.
I still see this primarily as a performance optimization. It's great if you want to lower your connectivity requirements or avoid the hit of loading an image when it is actually needed, but otherwise discrete images are probably the better option. I think the primary use case for this, as Edvin pointed out, is the ability to re-use existing web graphics rather than requiring the designer to cut them up. Developers will just need to be aware of the implications of using this feature (i.e. larger memory footprint).
G
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 13 July 2011 22:04, Greg Brown <gk...@verizon.net> wrote:
>> Maintaining & distributing a single image asset is easier than doing
>> so for potentially hundreds of small icons. This technique seems to
>> fit well when there is a grid of equally sized 'icons', and is
>> something I saw in game development aeons ago.
>
> I seem to recall that the Windows ListView component (way back) used to use this approach as well.
>
> One downside to this technique is that it will consume more memory than necessary - we'd need to maintain the entire image in memory even though we're only displaying one frame at a time. That doesn't seem like a good idea.
A single image might contain all icons required for a specific piece
of functionality. They might all be required up front, or at some
point in the app's lifecycle, so it is not necessarily true that more
is being held in memory than is required. If the 'large image'
contains 5 icons, which will always be displayed on my apps toolbar,
then having the option of loading a single asset and 'chunking' it up
at runtime might well be preferable to some than loading the same 5
icons from separate files.
I'm pretty sure that I would use it if the functionality were there,
but it would depend on the availability of the source data. If I only
had access to 50 individual icons, I doubt that I would go to the
trouble of building a single asset out of them, but given that single
asset, using it would be my preferred option.
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
OK, so specifying a clip region, rather than a row/column and icon size, would probably be best.
I wonder if this would be best implemented in Picture rather than ImageView?
On Jul 13, 2011, at 11:25 AM, SYSE | Edvin wrote:
> Den 13.07.2011 17:22, skrev Greg Brown:
>>> I agree that one mostly bundles the resources in a Pivot app, but the need is to reuse existing "web-sprites".
>>
>> OK. It does seem like providing the ability to specify some sort of clipping region might make sense. In such "sprites", are the icon sizes generally fixed? Or are the images likely to have different sizes?
>
> They sometimes have different sizes. Here is an example:
>
> https://www.syse.no/files/gfx-dark/tornado_icons_sprite_dark.png
>
> -- Edvin
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 17:22, skrev Greg Brown:
>> I agree that one mostly bundles the resources in a Pivot app, but the need is to reuse existing "web-sprites".
>
> OK. It does seem like providing the ability to specify some sort of clipping region might make sense. In such "sprites", are the icon sizes generally fixed? Or are the images likely to have different sizes?
They sometimes have different sizes. Here is an example:
https://www.syse.no/files/gfx-dark/tornado_icons_sprite_dark.png
-- Edvin
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
> I agree that one mostly bundles the resources in a Pivot app, but the need is to reuse existing "web-sprites".
OK. It does seem like providing the ability to specify some sort of clipping region might make sense. In such "sprites", are the icon sizes generally fixed? Or are the images likely to have different sizes?
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 13 July 2011 22:08, SYSE | Edvin <es...@syse.no> wrote:
> Den 13.07.2011 17:04, skrev Greg Brown:
>> That was my first thought - that it was an HTML-specific optimization.
>> This optimization generally won't be necessary in a Pivot app, since all of
>> the app's resources are likely to be bundled in a JAR.
>
> I agree that one mostly bundles the resources in a Pivot app, but the need
> is to reuse existing "web-sprites".
As mentioned in one of my other replies, I would certainly use this
for image assets if the functionality existed, even in a completely
offline app.
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 17:04, skrev Greg Brown:
>>> This is an interesting question. Why might a web designer want to use this technique versus discrete images?
>>
>> Look at this one:
>>
>> https://www.syse.no/files/gfx-dark/icons_64x64_cp.png
>>
>> That's a single http request instead of hm... MANY :)
>
> That was my first thought - that it was an HTML-specific optimization. This optimization generally won't be necessary in a Pivot app, since all of the app's resources are likely to be bundled in a JAR.
I agree that one mostly bundles the resources in a Pivot app, but the
need is to reuse existing "web-sprites".
-- Edvin
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
>> This is an interesting question. Why might a web designer want to use this technique versus discrete images?
>
> Look at this one:
>
> https://www.syse.no/files/gfx-dark/icons_64x64_cp.png
>
> That's a single http request instead of hm... MANY :)
That was my first thought - that it was an HTML-specific optimization. This optimization generally won't be necessary in a Pivot app, since all of the app's resources are likely to be bundled in a JAR.
> Maintaining & distributing a single image asset is easier than doing
> so for potentially hundreds of small icons. This technique seems to
> fit well when there is a grid of equally sized 'icons', and is
> something I saw in game development aeons ago.
I seem to recall that the Windows ListView component (way back) used to use this approach as well.
One downside to this technique is that it will consume more memory than necessary - we'd need to maintain the entire image in memory even though we're only displaying one frame at a time. That doesn't seem like a good idea.
G
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 16:45, skrev Greg Brown:
> This is an interesting question. Why might a web designer want to use this technique versus discrete images?
Look at this one:
https://www.syse.no/files/gfx-dark/icons_64x64_cp.png
That's a single http request instead of hm... MANY :)
-- Edvin
Re: ImageView support for sprite/offset
Posted by Greg Brown <gk...@verizon.net>.
This is an interesting question. Why might a web designer want to use this technique versus discrete images?
On Jul 13, 2011, at 10:37 AM, Chris Bartlett wrote:
> (Forwarded from the user list)
>
> Edvin,
>
> I can definitely see the value of being able to target a smaller
> 'chunk' of a larger image, (and have seen entire icon sets being
> distributed in a single 'contact sheet') but my gut reaction is that
> ImageView is not the right place for it.
>
> ImageView obviouly displays Image objects.
> http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/media/Image.html
>
> How about moving the logic into a custom Image class instead? Perhaps
> one that just 'decorates' other Images.
>
> ImageChunk imageChunk = new ImageChunk(someOtherImage);
> imageChunk.setOffset(100, 100);
> imageChunk.setSize(32, 32);
> ImageView imageView = new ImageView(imageChunk);
>
> Chris
>
>> On 13 July 2011 21:15, SYSE | Edvin <es...@syse.no> wrote:
>>> More and more often I come across existing web-graphics that needs to be
>>> reused in desktop-applications. Webdesigners are gradually shifting towards
>>> creating a sprite containing multiple images and using css to choose which
>>> image to show.
>>>
>>> I would like to propose a small change to ImageView to support this
>>> behavior, so that one can easier reuse existing web-graphics in
>>> desktop-applications. Provided is a patch that shows what I mean.
>>>
>>> Here is an example of it's usage. Take a look at the following picture:
>>>
>>> http://askjems.no/files/gfx/viewmodes_sprite.png
>>>
>>> Showing the first "icon" in this image can be done by restricting the
>>> maximum height to the height of each "icon":
>>>
>>> int iconHeight = 27;
>>> imageView.setPreferredHeight(iconHeight);
>>>
>>> My patch will allow you to do this to show the second "icon":
>>>
>>> imageView.getStyles().put("offsetY", iconHeight);
>>>
>>> Third icon:
>>>
>>> imageView.getStyles().put("offsetY", iconHeight * 2);
>>>
>>> offsetX is also supported, for multi column sprites. Does that make
>>> sense/look valuable?
>>>
>>> -- Edvin
>>>
>>
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
On 13 July 2011 21:52, SYSE | Edvin <es...@syse.no> wrote:
>> ImageChunk imageChunk = new ImageChunk(someOtherImage);
>> imageChunk.setOffset(100, 100);
>> imageChunk.setSize(32, 32);
>> ImageView imageView = new ImageView(imageChunk);
>
> With my initial approach, you can use a single Image instance for all
> ImageViews that use the same base image. Wouldn't this solution use far more
> resources?
> I think that approach is easier to explain and use, and it seems like it
> will have better performance if you load the image once instead of n times.
I was still thinking of only having a single instance of the source
image, not multiple ones. The 'chunks' returned would just be a small
viewport showing the relevant area of that source image. I haven't
thought it though in any level of detail, but don't see a reason why
it shouldn't have similar performance.
So another way of putting would be...
ImageChunkProvider imageChunkProvider = new ImageChunkProvider(sourceImage);
Image image1 = imageChunkProvider.getImage(100, 100, 32, 32); //
location x, location y, width, height
Image image2 = imageChunkProvider.getImage(200, 200, 32, 32); //
location x, location y, width, height
ImageView imageView1 = new ImageView(image1); // Show a chunk of sourceImage
ImageView imageView2 = new ImageView(image2); // Show a different
chunk of sourceImage
The provided Image would be pretty lightweight. Just an x&y location,
size and reference to the source image.
I'm not claiming this is better to your proposal, just an alternative.
One thing that this option offers is that you could switch the
'sourceImage' for another image to change icons sets, rather than
having to change it in multiple ImageViews. Anyway, not sure how
useful that would be in reality, just thinking out loud ;)
> I actually think it sounds reasonable that an ImageView can show part of an
> image, but I'm not religiously against your proposal either :)
> Can you elaborate on the gut feeling? You might be right, but I can't see myself why
> this doesn't belong in ImageView :)
I certainly don't think that an ImageView *shouldn't* be able to do
it, just that perhaps it might be a better fit elsewhere. Maybe
another suggestion will come along suggesting that ImageView be able
to show rotated images or something similar. I think it would be
clearer if ImageView just took care of displaying what it was provided
to it.
Chris
Re: ImageView support for sprite/offset
Posted by SYSE | Edvin <es...@syse.no>.
Den 13.07.2011 16:37, skrev Chris Bartlett:
> (Forwarded from the user list)
>
> Edvin,
>
> I can definitely see the value of being able to target a smaller
> 'chunk' of a larger image, (and have seen entire icon sets being
> distributed in a single 'contact sheet') but my gut reaction is that
> ImageView is not the right place for it.
>
> ImageView obviouly displays Image objects.
> http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/media/Image.html
>
> How about moving the logic into a custom Image class instead? Perhaps
> one that just 'decorates' other Images.
>
> ImageChunk imageChunk = new ImageChunk(someOtherImage);
> imageChunk.setOffset(100, 100);
> imageChunk.setSize(32, 32);
> ImageView imageView = new ImageView(imageChunk);
With my initial approach, you can use a single Image instance for all
ImageViews that use the same base image. Wouldn't this solution use far
more resources?
In a large sprite, that's a lot of images you would be creating
unnecessarily. One other "advantage" with my first approach is that the
markup for an offset'ed image will look very similary to a
none-offset'ed image:
<ImageView image="@single.jpg"/>
<ImageView image="@sprite.jpg" styles="{ offsetY: 27 }"/>
I think that approach is easier to explain and use, and it seems like it
will have better performance if you load the image once instead of n times.
I actually think it sounds reasonable that an ImageView can show part of
an image, but I'm not religiously against your proposal either :) Can
you elaborate on the gut feeling? You might be right, but I can't see
myself why this doesn't belong in ImageView :)
-- Edvin
Re: ImageView support for sprite/offset
Posted by Chris Bartlett <cb...@gmail.com>.
(Forwarded from the user list)
Edvin,
I can definitely see the value of being able to target a smaller
'chunk' of a larger image, (and have seen entire icon sets being
distributed in a single 'contact sheet') but my gut reaction is that
ImageView is not the right place for it.
ImageView obviouly displays Image objects.
http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/media/Image.html
How about moving the logic into a custom Image class instead? Perhaps
one that just 'decorates' other Images.
ImageChunk imageChunk = new ImageChunk(someOtherImage);
imageChunk.setOffset(100, 100);
imageChunk.setSize(32, 32);
ImageView imageView = new ImageView(imageChunk);
Chris
> On 13 July 2011 21:15, SYSE | Edvin <es...@syse.no> wrote:
>> More and more often I come across existing web-graphics that needs to be
>> reused in desktop-applications. Webdesigners are gradually shifting towards
>> creating a sprite containing multiple images and using css to choose which
>> image to show.
>>
>> I would like to propose a small change to ImageView to support this
>> behavior, so that one can easier reuse existing web-graphics in
>> desktop-applications. Provided is a patch that shows what I mean.
>>
>> Here is an example of it's usage. Take a look at the following picture:
>>
>> http://askjems.no/files/gfx/viewmodes_sprite.png
>>
>> Showing the first "icon" in this image can be done by restricting the
>> maximum height to the height of each "icon":
>>
>> int iconHeight = 27;
>> imageView.setPreferredHeight(iconHeight);
>>
>> My patch will allow you to do this to show the second "icon":
>>
>> imageView.getStyles().put("offsetY", iconHeight);
>>
>> Third icon:
>>
>> imageView.getStyles().put("offsetY", iconHeight * 2);
>>
>> offsetX is also supported, for multi column sprites. Does that make
>> sense/look valuable?
>>
>> -- Edvin
>>
>