|
Tiny Bug Child posted:why is this dumb aside from adding needless complexity to your code, if you ever update a single image on the sprite sheet all clients must essentially redownload all images instead of just the one image that was updated.
|
#
?
Nov 26, 2012 21:09
|
|
|
|
| # ? May 9, 2024 12:52 |
|
|
Tiny Bug Child posted:why is this dumb hey random q, how much do you hate adblock plus i havent gotten one porn popunder since i installed
|
|
#
?
Nov 26, 2012 21:15
|
|
|
Shaggar posted:aside from adding needless complexity to your code, if you ever update a single image on the sprite sheet all clients must essentially redownload all images instead of just the one image that was updated. i agree with you a lot of webdev stuff is dumb but i'm sure that an insurance company website has a pretty static set of images. to me it's not unlike batching your database calls and doing a little extra processing client side instead. assuming this wasn't all hand-coded it's probably pretty low on the totem pole of dumb things webdevs do
|
|
#
?
Nov 26, 2012 21:18
|
|
|
yeah, and if you change the image the servers might have to deal with several thousand requests for a 200kb file oh noooooo an idiot web dev thing would be to have it not replace the old cached image. or storing credit card numbers in plaintext.
|
|
#
?
Nov 26, 2012 21:19
|
|
|
so you get a poor user experience from longer page loads, more complex code for the developer to manage, and higher bandwidth usage. i guess that is standard practice for web "development"
|
|
#
?
Nov 26, 2012 21:25
|
|
|
don't get me wrong i'm not saying it's smart, seems like micro-optimization wankery that should be reserved for really high traffic sites, if it does indeed work as advertised just there's lots worse things web devs do all the time
|
|
#
?
Nov 26, 2012 21:30
|
|
|
i enjoyed coding once but then i realised it was an elite club for sociopaths and cat children and i just didnt feel ok about it after
|
|
#
?
Nov 26, 2012 21:31
|
|
|
i hate coding, people, the earth, being alive, etc
|
|
#
?
Nov 26, 2012 21:46
|
|
|
Socracheese posted:i hate coding, people, the earth, being alive, etc i dont hate the earth, the earth is 1 cool motherfucker the rest though
|
|
#
?
Nov 26, 2012 21:49
|
|
|
I do the PNG spritesheet thing too but it's loving huge so I probably need to find alternatives OTOH once it's fully loaded people can put stuff together out of clips from that spritesheet and you can see live previews flash past as you move the mouse across the options in the dropdown and it srsly ownz
|
|
#
?
Nov 26, 2012 21:55
|
|
|
me too
|
|
#
?
Nov 26, 2012 21:56
|
|
|
Shaggar posted:aside from adding needless complexity to your code, if you ever update a single image on the sprite sheet all clients must essentially redownload all images instead of just the one image that was updated. Your regular browser won't allow that many concurrent connections per host. IE7 and other older browsers allow 2, IE8 allows 6, Chrome goes for 6, FF for 8 and used to be 4, etc. Over each of these, you may then attempt to pipeline requests. Opera fully supports proper pipelining, Chrome does it over HTTP only, IE8 doesn't make use of it due to potential head-of-line blocking, and FF disables it by default. This means that in general, if your images are on a single domain, you will only download from 2 to 8 of them at a time. The rest will be queued up, until the connections are closed, renegotiated, and finally downloaded to slowly appear when possible. Assuming you still allow pipelining though that requires you to pass around cookies and HTTP headers (including cache info) every time. In the general case, you should assume there's no pipelining. Given this, you should shard your images across many subdomains of a CDN and evenly round-robin (or randomly) go through these to allow maybe 16-32 connections instead of 2-8, to pull random numbers. This will drastically improve perceived speed by the client. Then you should ideally sprite small images together, especially icons given HTTP headers, cookies, and poo poo, may end up weighing nearly as much as the image. Huge overhead for no reason. By spriting them, you use one connection, one transmission of client-side data only. It's a bit useless to make sprites out of huge images given how little that saves compared to sharding domains. You may find out it helps gzipping them and cache in general, though, but it's very possible it makes things slower than if you sharded domains in the first place. To add more, if you take your standard web site and call it with some timers, you'll find out a huge part of the load time you get comes from assets being queued up in the background -- a lot more than whatever language is used by the server, and most of the time, the database chosen. Optimizing how static assets are downloaded is likely a better time investment than most server-side optimization you could decide to make. </sperg> MononcQc fucked around with this message at 22:05 on Nov 26, 2012 |
|
#
?
Nov 26, 2012 22:01
|
|
|
MononcQc posted:Your regular browser won't allow that many concurrent connections per host. IE7 and other older browsers allow 2, IE8 allows 6, Chrome goes for 6, FF for 8 and used to be 4, etc.
|
|
#
?
Nov 26, 2012 22:27
|
|
|
MononcQc posted:Your regular browser won't allow that many concurrent connections per host. IE7 and other older browsers allow 2, IE8 allows 6, Chrome goes for 6, FF for 8 and used to be 4, etc. forever owned by bad web specs. cant wait till web "developers" fashion a solution to the connection limit problem by using unlimited websocket connections.
|
|
#
?
Nov 26, 2012 22:41
|
|
|
Shaggar posted:forever owned by bad web specs. cant wait till web "developers" fashion a solution to the connection limit problem by using unlimited websocket connections. Bad web specs are a part of it. I have no proof but I'm pretty sure an important part of it is to make it harder for browsers to inadvertently DDoS servers that have many images to the same server by spamming them with dozens or hundreds of fresh connections.
|
|
#
?
Nov 26, 2012 22:44
|
|
|
Shaggar posted:aside from adding needless complexity to your code, if you ever update a single image on the sprite sheet all clients must essentially redownload all images instead of just the one image that was updated. lol shaggar doesn't understand web development
|
|
#
?
Nov 26, 2012 22:44
|
|
|
Jonny 290 posted:hey random q, how much do you hate adblock plus i don't hate it at all, anyone who installs adblock plus is not going to pay for porn anyway
|
|
#
?
Nov 26, 2012 22:45
|
|
|
Shaggar posted:forever owned by bad web specs. the limit on concurrent connections is not in any spec shaggar come on, you could at least have gone for the beautiful webs angle or something
|
|
#
?
Nov 26, 2012 22:49
|
|
|
it's the monday after a holiday, give him a few days to spin it back up
|
|
#
?
Nov 26, 2012 22:50
|
|
|
MononcQc posted:Bad web specs are a part of it. I have no proof but I'm pretty sure a more important part of it is to make it harder for browsers to inadvertently DDoS servers that have many images to the same server by spamming them with dozens or hundreds of fresh connections. i dont see how an arbitrary spec protects against that. the browsers most likely to have internal bugs that cause it to do too many requests are either gonna ignore the spec anyway or allow the user to choose to ignore it (ex: failurefox). and any web "developer" who creates "code" that generates too many requests or a request loop deserves to have their servers flooded. they'll be real quick to fix it. as opposed to it being hidden behind piles of slow from their other code when connections are limited. since servers have 0 control over browser clients everyone has to operate in good faith. since this is the case why not suggest the connection limit to the client in another header or something. its kind of a hack, but if you really wanted to fix it you'd overhaul the http spec because its way way way out of date.
|
|
#
?
Nov 26, 2012 22:55
|
|
|
just base64 all the images and inline them in the html imo
|
|
#
?
Nov 26, 2012 22:58
|
|
|
i agree with shaggar. instead of sprite sheets, web sites should use canvases and procedural generation
|
|
#
?
Nov 26, 2012 23:00
|
|
|
Wheany posted:i agree with shaggar. canvas is sorta cool but svg is better because vectors.
|
|
#
?
Nov 26, 2012 23:02
|
|
|
Shaggar posted:i dont see how an arbitrary spec protects against that. the browsers most likely to have internal bugs that cause it to do too many requests are either gonna ignore the spec anyway or allow the user to choose to ignore it (ex: failurefox). and any web "developer" who creates "code" that generates too many requests or a request loop deserves to have their servers flooded. they'll be real quick to fix it. as opposed to it being hidden behind piles of slow from their other code when connections are limited. There's no proper spec regarding how many connections you can have. You may call it a bad spec or not due to omission if you want. Part of it is also the lack of a 'session' concept, which can be both positive and negative, depending of the kind of content you serve. Such sessions could impose limits on concurrent connections (for example, BOSH limits to 1 connection per session by design). The original HTTP specs had more to do about documents and 'resources' as a broader concept than your-fun-hip-bay-area-web-app-of-the-month that uses a browser like a thin client, so I'd rather call it a bad choice of protocol for the app, rather than a badly designed protocol. Servers do not necessarily operate in good faith. If you write a web app that trusts anybody you likely have a security shithole. The connection limit is a tricky thing in the first place, in any case. Proper pipelining would help a good bit to reduce how many connections you want for small content, but that's not the end of it anyway. A high connection limit is alright when they don't last long and can be cleared fast, but when they're incredibly slow, it becomes unclear whether you're dealing with a slow client, someone with high latency (say, satellite), or a plain old Slowloris-like DDoS attack.
|
|
#
?
Nov 26, 2012 23:05
|
|
|
http is designed for a particular thing but somehow we've decided to tunnel all traffic through it and it's terrible.
|
|
#
?
Nov 26, 2012 23:08
|
|
|
also you can just generate your image data, base64-encode it and set it as a data:url to an image tag. come on people, this is not rocket science.
|
|
#
?
Nov 26, 2012 23:10
|
|
|
MononcQc posted:</sperg> rotor posted:just base64 all the images and inline them in the html imo yeah this is pretty dumb thing already but I think I can do better than that how about sending uncompressed binary data encoded as a PNG image using its inbuilt compression to avoid having to configure your web server to compress http responses:  but if that doesn't have you shaking your head already, it doesn't have to stop there, this technique could be taken further you could encode all your static .html, .js, .css files in with the sprite sheet, then you could dump your user-viewable database in binary, serve it with a second http get and run javascript queries against that, no further network traffic required! but wait, PNG is an extendable format where any unknown chunks are supposed to be ignored by browsers, so what if we could include java applets, Silverlight w/e things, windows 8 metro apps, etc in that initial static file bundle that's going to end up cached everywhere, we could do a real optimized cross-platform software bundle
|
|
#
?
Nov 26, 2012 23:11
|
|
|
gently caress you
|
|
#
?
Nov 26, 2012 23:14
|
|
|
duTrieux. posted:gently caress you
|
|
#
?
Nov 26, 2012 23:15
|
|
|
Win8 Hetro Experie posted:yeah this is pretty dumb thing already meet gifsockets, allowing you to continuously stream data through animated GIFs.
|
|
#
?
Nov 26, 2012 23:15
|
|
|
MononcQc posted:meet gifsockets, allowing you to continuously stream data through animated GIFs. gently caress webs
|
|
#
?
Nov 27, 2012 00:31
|
|
|
MononcQc posted:meet gifsockets, allowing you to continuously stream data through animated GIFs. lol so someone gonna use this to cause people to go over on their mobile data plans?
|
|
#
?
Nov 27, 2012 00:35
|
|
|
quote:Since a gif image doesn't specify how many frames it has, once the browser opens it, it will keep waiting for new frames until you send the bits indicating that there's no more image to fetch. i'm dying here lmbo
|
|
#
?
Nov 27, 2012 00:36
|
|
|
Cold on a Cob posted:lol so someone gonna use this to cause people to go over on their mobile data plans? we've already got a bunch of ways to do this, even apple did it.
|
|
#
?
Nov 27, 2012 00:37
|
|
|
duTrieux. posted:gently caress you
|
|
#
?
Nov 27, 2012 02:18
|
|
|
MononcQc posted:meet gifsockets, allowing you to continuously stream data through animated GIFs. huh now i know why chrome sucks at gifs. thanks
|
|
#
?
Nov 27, 2012 02:22
|
|
|
Shaggar posted:forever owned by bad web specs. cant wait till web "developers" fashion a solution to the connection limit problem by using unlimited websocket connections. I can tell how little you understand web development by the way that you think you're talking about the future here.
|
|
#
?
Nov 27, 2012 19:15
|
|
|
web "development" is bad. thats all there is to it.
|
|
#
?
Nov 27, 2012 21:41
|
|
|
lol if you unironically think web sockets are a good idea.
|
|
#
?
Nov 27, 2012 21:41
|
|
|
|
| # ? May 9, 2024 12:52 |
|
|
are they anything like "socks", that you put on your feet? I cant see how they relate
|
|
#
?
Nov 27, 2012 21:55
|
|