5 ms·

It seems inflexible and potentially inefficient though. What if you have 2x assets available for some images but not others? Will the client be making two reque

by tpenzer 14y ago

It seems inflexible and potentially inefficient though. What if you have 2x assets available for some images but not others? Will the client be making two requests in all those cases? Or will it simply break?

KrisJordan 14y ago
Server logic can figure it out just fine. For a familiar example check out nginx's static gzip compression support [1]. This works today. Browsers can say they support gzip compressed assets in a header. You don't have to add markup to say "get the smaller version". When nginx gets a request it looks to see "is gzip on the accept-encoding list"? If so, it looks to see if a compressed version of the file is sitting on the server and serves that directly. If not, it compresses on the fly. Same story could apply here with a few different details. [1]: http://wiki.nginx.org/HttpGzipStaticModule http://wiki.nginx.org/HttpGzipStaticModule
- tpenzer 14y ago
  I don't understand how that resolves the issue. Let's say you have two img elements on your page, linking to their respective 1x image assets, and you have a 2x version of the image available for the first but not the second. You indicate 2x availability in your HTTP header, and a client which supports this protocol wishes to display 2x images. Does the client specifically request 2x image file paths for both images, and when the second one fails, as no 2x version exists, the client makes another request for the 1x version, or does it simply fail to load the image? Or does the client request the 1x asset like usual, and when the server determines that one is unavailable in 2x res, it sends the 1x transparently? If that's the case, do we not care about the server using resources determining availability of individual 2x assets because it's insignificant? And could the client easily choose to request 1x assets rather than 2x in a non-hackish way even if it does support 2x resolution (maybe it's concerned about bandwidth)?
  - plorkyeran 14y ago
    You indicate 2x availability in your HTTP header This part never happens. The client simply signals that it would like 2x images if possible with every request, and the server sends the 2x images when it is possible, and 1x images when not. This is the exact same thing as has been done with gzip compression for years. The client can choose to get 1x assets by just not sending the header indicating that it wants 2x assets.
    - tpenzer 14y ago
      And what about the performance penalty for the server to determine 2x availability for sites where only a fraction of images are available at 2x res? I'm also not sure I fully understand how we clue the server in on where to look for the 2x version of a 1x asset. In the examples given, do the 2x versions have the same filenames as the 1x versions, but they're in the 'image' directory rather than 'img'? Seems like a significant limitation to force different assets to share the same filename, if that's what's going on here.
X-Istence 14y ago
You send back the 2x assets where possible and otherwise return the standard asset that is not 2x.

by tpenzer 14y ago

KrisJordan 14y ago

Server logic can figure it out just fine. For a familiar example check out nginx's static gzip compression support [1]. This works today. Browsers can say they support gzip compressed assets in a header. You don't have to add markup to say "get the smaller version". When nginx gets a request it looks to see "is gzip on the accept-encoding list"? If so, it looks to see if a compressed version of the file is sitting on the server and serves that directly. If not, it compresses on the fly. Same story could apply here with a few different details. [1]: http://wiki.nginx.org/HttpGzipStaticModule http://wiki.nginx.org/HttpGzipStaticModule

tpenzer 14y ago
I don't understand how that resolves the issue. Let's say you have two img elements on your page, linking to their respective 1x image assets, and you have a 2x version of the image available for the first but not the second. You indicate 2x availability in your HTTP header, and a client which supports this protocol wishes to display 2x images. Does the client specifically request 2x image file paths for both images, and when the second one fails, as no 2x version exists, the client makes another request for the 1x version, or does it simply fail to load the image? Or does the client request the 1x asset like usual, and when the server determines that one is unavailable in 2x res, it sends the 1x transparently? If that's the case, do we not care about the server using resources determining availability of individual 2x assets because it's insignificant? And could the client easily choose to request 1x assets rather than 2x in a non-hackish way even if it does support 2x resolution (maybe it's concerned about bandwidth)?
- plorkyeran 14y ago
  You indicate 2x availability in your HTTP header This part never happens. The client simply signals that it would like 2x images if possible with every request, and the server sends the 2x images when it is possible, and 1x images when not. This is the exact same thing as has been done with gzip compression for years. The client can choose to get 1x assets by just not sending the header indicating that it wants 2x assets.
  - tpenzer 14y ago
    And what about the performance penalty for the server to determine 2x availability for sites where only a fraction of images are available at 2x res? I'm also not sure I fully understand how we clue the server in on where to look for the 2x version of a 1x asset. In the examples given, do the 2x versions have the same filenames as the 1x versions, but they're in the 'image' directory rather than 'img'? Seems like a significant limitation to force different assets to share the same filename, if that's what's going on here.

X-Istence 14y ago

You send back the 2x assets where possible and otherwise return the standard asset that is not 2x.