Sprite sheets

[Michel_Bujardet]

@116785:@Greg O'Lone

It doesn’t surprise me that this doesn’t work. You’re essentially adding a second body tag to the html file which is not really allowed. Additionally, WebPages are drawn on top of the body so the background is getting obscured.

I suspected as much. It would be a nice feature to be able to use tiling in the page background, though, as HTML pages do. Instead of one bulky picture, a small image could often create a nice effect.

[quote=116807:@Richard Corlett]I was also faced the same problem with creating background tiling this way, so I use a JavaScript instead:
There is already a feature request <https://xojo.com/issue/16576> in Feedback.[/quote]

Great workaround. Thank you Richard for posting it

I also added my voice to FR 16576.

[Michel_Bujardet]

Brock has added a great contribution to the feature request 34680 - Sprite sheet support for WE. In particular, he proposes to add to WebImageView scaling, position, and repeat.

That made me realize that the workaround program I posted on my site simply does position of the picture, and it already performs well. Tiling seems like a very elegant way to generate bigger images without gobbling bandwidth.

I am not too sure about scaling, though, as I do not see how the framework could do anything other than create a new picture, which would generate bulk and defeat the purpose of sprite sheets memory and bandwidth management.

Anyway, I noticed the FR was ranked 87 : it is quite encouraging. Fingers crossed

[Richard_Corlett]

@116818:@Michel Bujardet

I am not too sure about scaling, though, as I do not see how the framework could do anything other than create a new picture, which would generate bulk and defeat the purpose of sprite sheets memory and bandwidth management.

I suspect the problem you would run into with scaling images is that it would not be supported on older browsers.

[Michel_Bujardet]

@116823:@Richard Corlett

I suspect the problem you would run into with scaling images is that it would not be supported on older browsers.

Well ; CSS is definitely badly supported by earlier versions of IE, so for older versions, there seems to be no other way than creating a new picture.

Somehow, I feel scaling is not quite related to sprite sheets and tiling. The whole idea of sprite sheets is simply to position the picture in a view window instead of loading separate icons. And tiling is about reusing the same image several times instead of using a huge picture. No scaling involved. Besides, tiling has been used forever and should not pose any compatibility problem. As for sprite sheets, they seem to have existed since the very beginning of CSS, so it should be mostly alright.

At first glance, and since these are HTML features, they seem possible to integrate in WE relatively rapidly. But I maybe speculating without knowing. In the meantime, workarounds like what I did and what you posted can already provide some relief. I worked yesterday on using CSS Sprite Sheets within a WebDSK control, and it works beautifully. So even client side sprite sheets can now be accessed.

[Richard_Corlett]

CSS Sprites come into their own where you need the image to change instantly, as in response to a mouse hover for example. By the way, I had tried doing the same thing with JavaScripts and separate images, but there was always a slight delay until the second image loaded. Once the second image was available it worked fast enough.

[Michel_Bujardet]

@116845:@Richard Corlett

CSS Sprites come into their own where you need the image to change instantly, as in response to a mouse hover for example. By the way, I had tried doing the same thing with JavaScripts and separate images, but there was always a slight delay until the second image loaded. Once the second image was available it worked fast enough.

CSS Sprite sheets indeed are very fast, and that makes sense. Once the sheet is in the browser cache, no need to wait for any additional load. No matter the speed of a program (and JS if fast) downloading separate images always take time.

[Brock_Nash]

Browsers already support the scaling. Essentially if I have a button that’s 100x100 and I want it on an imageview that’s 50x50. Instead of the image being clipped, I should be able to make it “fit”. I’m honestly surprised this doesn’t already exist on the WebImageView. Also instead of having to render 100x100 and 50x50 versions of the image, one simply needs the 100x100 version. This also makes a lot of sense with the WebAnimator: For example, I often want to have big buttons on a home screen and then shrink and animate them down into a menu after you click one. Browsers already work with this, we just need a scale or at least a “fit” option on the WebImageView.

[Michel_Bujardet]

@117240:@Brock Nash

Browsers already support the scaling. Essentially if I have a button that’s 100x100 and I want it on an imageview that’s 50x50. Instead of the image being clipped, I should be able to make it “fit”. I’m honestly surprised this doesn’t already exist on the WebImageView. Also instead of having to render 100x100 and 50x50 versions of the image, one simply needs the 100x100 version. This also makes a lot of sense with the WebAnimator: For example, I often want to have big buttons on a home screen and then shrink and animate them down into a menu after you click one. Browsers already work with this, we just need a scale or at least a “fit” option on the WebImageView.

You are right, browsers do support scaling. Indeed it should not be too much of a hassle to implement.

In the meantime, I just used HTML to scale a picture in a HTMLArea WebSDK control. Easy as pie and real nice.