Re: "Retina" sprite generation

[Stanislaw Osinski]

Hi Dan,

There's no support for Retina sprites, yet. A patch/fork would be most welcome (I'm swamped with other work...)!

Thanks,

Stanislaw

On Wed, Feb 13, 2013 at 11:54 PM, Dan Polivy <dan.p...@gmail.com> wrote:

Has anyone successfully used smartsprites to generate sprites for use on high dpi displays? (e.g. http://brianistech.wordpress.com/2011/05/11/ios-retina-sprites/)

We're using it for regular sprites without issues, but I'm having trouble getting it to work with my 2x images; I think the main issue is the background-position should be the adjusted by the ratio between the specified background-size and the actual sprite size. Or, to put it more simply, when dealing with images that are twice the size, the background position should be 50% of what it is in order for the scaling to work properly.

I'll probably fork the code and take a stab at this if no one else has figured it out, but I wanted to ask first.

Dan

--
You received this message because you are subscribed to the Google Groups "SmartSprites CSS Sprite Generator Users and Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smartsprites-css-sprit...@googlegroups.com.
To post to this group, send email to smartsprites-css...@googlegroups.com.
Visit this group at http://groups.google.com/group/smartsprites-css-sprite-generator?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dan Polivy]

OK, I'll give it a shot and let you know if I come up with anything useful. My Java is...rusty...to say the least. :)

Dan

On Thursday, February 14, 2013 1:47:10 AM UTC-8, Stanislaw Osinski wrote:

Hi Dan,

There's no support for Retina sprites, yet. A patch/fork would be most welcome (I'm swamped with other work...)!

Thanks,

Stanislaw

On Wed, Feb 13, 2013 at 11:54 PM, Dan Polivy <dan.p...@gmail.com> wrote:

Has anyone successfully used smartsprites to generate sprites for use on high dpi displays? (e.g. http://brianistech.wordpress.com/2011/05/11/ios-retina-sprites/)

We're using it for regular sprites without issues, but I'm having trouble getting it to work with my 2x images; I think the main issue is the background-position should be the adjusted by the ratio between the specified background-size and the actual sprite size. Or, to put it more simply, when dealing with images that are twice the size, the background position should be 50% of what it is in order for the scaling to work properly.

I'll probably fork the code and take a stab at this if no one else has figured it out, but I wanted to ask first.

Dan

--
You received this message because you are subscribed to the Google Groups "SmartSprites CSS Sprite Generator Users and Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smartsprites-css-sprite-generator+unsubscribe@googlegroups.com.
To post to this group, send email to smartsprites-css-sprite-gene...@googlegroups.com.

[Dan Polivy]

I was able to add a new directive (sprite-scale) to the sprite image directive, and have successfully generated a high DPI compatible sprite with our existing stylesheet! I haven't used Java in over 10 years, so getting the build going was a little complicated, but in the end it wasn't so bad.

The idea is that you could specify your desired scaling factor PER SPRITE IMAGE, and then all images in that sprite will be processed given that scale ratio. That means the background-position will be adjusted by the scale, and if the scale is not 1, a background-size property will also be emitted.

I initially implemented this value as a float -- but am thinking about changing it to an int. I'm assuming most folks will simply want to double their images vs use an arbitrary scale factor. What are your thoughts on this?

Also, in order to get my newly forked/cloned repository to build on my machine, I had to make a few changes to the test code. Here's my version information:

Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: c:\Projects\apache-maven-3.0.4
Java version: 1.7.0_13, vendor: Oracle Corporation
Java home: C:\Program Files\java\jdk1.7.0_13\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

1) I was getting an ambiguous reference error on the Message class constructor. I fixed this by removing the "convenience" constructor (the one with fewer parameters), and adding in the necessary parameters to the handful of calls that needed them. Is this a JDK/compiler issue?

2) Two of the tests (absolute-image-url and non-default-output-dir) needed a few tweaks to the css files. For both, the MD5 hash in the expected file was different than what was generated. I removed the md5 hash as it appeared you wanted to deprecate that directive in the future. Also, the non-default-output-dir needed a tweak to not delete the original source images when it cleans up.

Are these two issues known with the current state of the codebase, or somehow related to my configuration?

Is there any way to build the install package using mvn? I haven't been able to figure that one out yet. Though I was able to manually piece together all of the dependencies to get it to work instead of my existing installation for another project.

Once I get some feedback on the float/int thing, I can commit my code and send it back your way.

Dan

[Stanislaw Osinski]

Hi Dan,

I was able to add a new directive (sprite-scale) to the sprite image directive, and have successfully generated a high DPI compatible sprite with our existing stylesheet! I haven't used Java in over 10 years, so getting the build going was a little complicated, but in the end it wasn't so bad.

Well done! Don't blame yourself for the build-related issues, most of the time it's Maven's fault ;-)

 

The idea is that you could specify your desired scaling factor PER SPRITE IMAGE, and then all images in that sprite will be processed given that scale ratio. That means the background-position will be adjusted by the scale, and if the scale is not 1, a background-size property will also be emitted.

That sounds reasonable. My thinking is that in most real-world scenarios it wouldn't make much sense to mix different scale images in one sprite, right? You either have Retina and use 2x images or not and then use the 1x ones.

 

I initially implemented this value as a float -- but am thinking about changing it to an int. I'm assuming most folks will simply want to double their images vs use an arbitrary scale factor. What are your thoughts on this?

Actually, some devices have the 1.5x pixel ratio, so float is the way to go, I think.

 

Also, in order to get my newly forked/cloned repository to build on my machine, I had to make a few changes to the test code. Here's my version information:

Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: c:\Projects\apache-maven-3.0.4
Java version: 1.7.0_13, vendor: Oracle Corporation
Java home: C:\Program Files\java\jdk1.7.0_13\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

1) I was getting an ambiguous reference error on the Message class constructor. I fixed this by removing the "convenience" constructor (the one with fewer parameters), and adding in the necessary parameters to the handful of calls that needed them. Is this a JDK/compiler issue?

I'm seeing this issue too, it must be a compiler bug fixed in JDK7. Ultimately, I'll probably create static factory methods in Message and disambiguate by method name, but feel free to leave your current approach, I can fix that later.

 

 

2) Two of the tests (absolute-image-url and non-default-output-dir) needed a few tweaks to the css files. For both, the MD5 hash in the expected file was different than what was generated. I removed the md5 hash as it appeared you wanted to deprecate that directive in the future. Also, the non-default-output-dir needed a tweak to not delete the original source images when it cleans up.

Are these two issues known with the current state of the codebase, or somehow related to my configuration?

I noticed you created a fork, so if you push your changes to your branch, I can pull then and take a look at the changes.

 

Is there any way to build the install package using mvn? I haven't been able to figure that one out yet. Though I was able to manually piece together all of the dependencies to get it to work instead of my existing installation for another project.

If you do: mvn -Prelease clean package, you should see the release ZIP in the target/ directory. 

 

Once I get some feedback on the float/int thing, I can commit my code and send it back your way.

Please go ahead, I'll bring your patch in and make an official release, it really high time...

Thanks a log for your contribution!

S.

[Dan Polivy]

Hi Stanislaw,

On Friday, February 15, 2013 6:20:21 AM UTC-8, Stanislaw Osinski wrote:

 

The idea is that you could specify your desired scaling factor PER SPRITE IMAGE, and then all images in that sprite will be processed given that scale ratio. That means the background-position will be adjusted by the scale, and if the scale is not 1, a background-size property will also be emitted.

That sounds reasonable. My thinking is that in most real-world scenarios it wouldn't make much sense to mix different scale images in one sprite, right? You either have Retina and use 2x images or not and then use the 1x ones.

While I haven't tried multiple scale values in the same sprite, in theory I think it might work; you'd just have to be sure to emit the properly scaled background-position and background-size tags for each image based on its individual scale ratio. But, I don't think there's much benefit to this approach. The main reason you'd keep the 2x images separate is because they're bigger, and you don't want folks to download them if they don't actually need them--so my thinking is that most folks will want to keep sprites separate based on the scale ratio.  If that assumption proves to be incorrect, it shouldn't be that hard to add a per-reference directive to override the scale.

 

I initially implemented this value as a float -- but am thinking about changing it to an int. I'm assuming most folks will simply want to double their images vs use an arbitrary scale factor. What are your thoughts on this?

Actually, some devices have the 1.5x pixel ratio, so float is the way to go, I think.

True -- but it's more likely folks will stick to a single ratio (e.g. 2x) and just let the browsers scale as appropriate. More pixels never hurt, except the download size :) But either way, I left it as a float. I also put in some log warnings so that if any of the calculated dimensions (per-reference or per-sprite) are fractional, smartsprites will let you know. That generally means your scaling isn't correct and the resulting image won't look exactly right. 

 

1) I was getting an ambiguous reference error on the Message class constructor. I fixed this by removing the "convenience" constructor (the one with fewer parameters), and adding in the necessary parameters to the handful of calls that needed them. Is this a JDK/compiler issue?

I'm seeing this issue too, it must be a compiler bug fixed in JDK7. Ultimately, I'll probably create static factory methods in Message and disambiguate by method name, but feel free to leave your current approach, I can fix that later.

Done.

 

2) Two of the tests (absolute-image-url and non-default-output-dir) needed a few tweaks to the css files. For both, the MD5 hash in the expected file was different than what was generated. I removed the md5 hash as it appeared you wanted to deprecate that directive in the future. Also, the non-default-output-dir needed a tweak to not delete the original source images when it cleans up.

Are these two issues known with the current state of the codebase, or somehow related to my configuration?

I noticed you created a fork, so if you push your changes to your branch, I can pull then and take a look at the changes.

Sounds good. I cleaned up my changes, commited to GitHub, and opened a pull request for you to review. Let me know if you have any questions. I didn't update the documentation, though.

If you do: mvn -Prelease clean package, you should see the release ZIP in the target/ directory. 

That works, thanks!

Please go ahead, I'll bring your patch in and make an official release, it really high time...

Thanks a log for your contribution!

Sounds great! My pleasure to help -- the tool has been quite useful for me, so happy to contribute back.

Dan

[Stanislaw Osinski]

Hi Dan,

That sounds reasonable. My thinking is that in most real-world scenarios it wouldn't make much sense to mix different scale images in one sprite, right? You either have Retina and use 2x images or not and then use the 1x ones.

While I haven't tried multiple scale values in the same sprite, in theory I think it might work; you'd just have to be sure to emit the properly scaled background-position and background-size tags for each image based on its individual scale ratio. But, I don't think there's much benefit to this approach. The main reason you'd keep the 2x images separate is because they're bigger, and you don't want folks to download them if they don't actually need them--so my thinking is that most folks will want to keep sprites separate based on the scale ratio.  If that assumption proves to be incorrect, it shouldn't be that hard to add a per-reference directive to override the scale.

I don't thing we'll ever need to combine 1x and 2x images, it's perfectly fine to keep them separate.

 

I initially implemented this value as a float -- but am thinking about changing it to an int. I'm assuming most folks will simply want to double their images vs use an arbitrary scale factor. What are your thoughts on this?

Actually, some devices have the 1.5x pixel ratio, so float is the way to go, I think.

True -- but it's more likely folks will stick to a single ratio (e.g. 2x) and just let the browsers scale as appropriate. More pixels never hurt, except the download size :) But either way, I left it as a float. I also put in some log warnings so that if any of the calculated dimensions (per-reference or per-sprite) are fractional, smartsprites will let you know. That generally means your scaling isn't correct and the resulting image won't look exactly right. 

If someone wanted to support 1.5x devices and prepared the images correctly (with dimensions divisible by 3), then they shouldn't see the warning. The 1.5x devices are less common these days, but since it's relatively simple to support them, it's a wise choice I think.

 

 Sounds good. I cleaned up my changes, commited to GitHub, and opened a pull request for you to review. Let me know if you have any questions. I didn't update the documentation, though.

Thanks! I'll try to merge and make the 0.2.9 release with your patch included later this week.

S.

[Detlef Beyer]

Hi,

first of all: thanks for this nice tool!

I'm testing Smartsprites and everything works fine so far - I ran only into one problem: retina sprites. I still have no concept how to integrate the sprite-scale option into my workflow.

What I want to do:

- to have one source CSS file

- to have one CSS class for each background image

- to get two sprites: normal and retina (sprite-scale: 2.0) from Smartsprite

- I load a second CSS file to overwrite the background-image property of the classes (background-image: url('/img/icons/retina_icons.png');) when I like to load the retina versions. Without this second file the normal version will be used.

Right now what I have to do:

- have two class definitions for one image: one normal and one retina definition (two CSS files?!)

- for the retina version I have to enter the image in the CSS class with the original size (20px) instead of the target size (50% = 10px) and use the sprite-scale: 2.0 option for the sprite. This results in images within my source CSS that are twice as large as they should be while working on a page and before smartsprites generates the new CSS file.

At the moment with SmartSprites I see only one option:

- use the retina resolution all the time (still with the problem that my source CSS file shows the image with the retina dimensions)

or

- work with two source CSS-Files for Smartsprites

What I like to have:

and optional parameter to specify and 2nd sprite for each resource - like:

    background-image: url(../img/web.gif); /** sprite-ref: standard_icons; retina-ref: retina_icons */

and the two sprite definitions:

/** standard_icons: sprite-image: url('/img/icons/sprite_icons.png'); */

/** retina_icons: sprite-image: url('/img/icons/retina_icons.png'); sprite-scale: 2.0; */

Cheers,

Detlef

[Dan Polivy]

Hi Detlef,

Sorry, just saw your questions now -- not sure if you were able to find a solution already. With the implementation I put together, you'd have to either combine all of your normal and retina sprites into a single CSS file, or have two source CSS files; there isn't any way to have it generate a separate output file just based on the scale/media queries. You could certainly look at modifying the code to support that if you wanted.

In my workflow, I pretty much always reference the sprited output files even in development, so the retina size issue you mention is not a concern for me. I'm not sure if that's possible for you in your workflow?

Dan

--
You received this message because you are subscribed to a topic in the Google Groups "SmartSprites CSS Sprite Generator Users and Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smartsprites-css-sprite-generator/wqw5rtRIGbA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smartsprites-css-sprit...@googlegroups.com.

To post to this group, send email to smartsprites-css...@googlegroups.com.

Visit this group at http://groups.google.com/group/smartsprites-css-sprite-generator.

[Detlef Beyer]

Hi Dan,

thanks for the reply. The reason behind having two css-files - one with retina and one with the standard sprites is simple. Mediaqueries don’t consider the quality of service (performance of the internet connection) and I don’t want to deliver images four times the size if the user comes with a poor connection speed.

Anyhow - I switched to SASS recently and can realize my workflow there the way I like it.

Thanks a lot for your nice tool!

Detlef

--
Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result.