Author: Richard A. Fowell (fowell@netcom.com)
Date: 19:21:39 01/08/00
Go up one level in this thread
On January 08, 2000 at 18:52:26, Tim Mirabile wrote: >On January 08, 2000 at 15:37:28, Richard A. Fowell (fowell@netcom.com) wrote: > >>Tim's HTML for an empty black square at the left edge of board: >> >><tr><td bgcolor="#009966"><img src="/diagram/es.gif" border=0 alt="::" >>width="34" height="35"> > >How did that border=0 get in there. Must be since I used my HTML editor to >write Perl. :) I can take that out (I think) since I'm not linking the images. Great - that will save a little bit. >Remember I save 13 images this way, not 7. Oops! I forgot that you need 6 black pieces, 6 white pieces, and 1 empty square, whereas the other approach uses 12 black pieces (dark & light square sets), 12 white pieces, and 2 empty squares (dark & light). I have observed in the past, when first entering a "puzzle piece board" site, noticing the white cells fill in one by one as the GIFs are loaded, so it seems like your approach must have an advantage in initially loading a page. >Bandwidth saved will depend on how >well they are cached by each person's browser. Also, having width and height is >a "good thing". Without it, some browsers will not show any text until all the >images are loaded which could affect the positioning of that text. With the H+W >you can start reading text while waiting for the images. Not much of an issue >here since the images are less than 1K each, but could help on a laggy >connection. In I.E. the whole page layout may jump around as each image is >loaded - yuck. Glad I use Netscape and Lynx, then. However this definitely sound worth doing. Seems a shame to have to call out width/height for every cell, though - does HTML not have a way to specify a default width/height for the cells in a table? > >Disk space is not an issue since this HTML is generated on the fly and never >stored. Perhaps CPU usage on the server could be a factor but when the server >is running well, the whole script runs quite fast. Sounds good. In this modern age, given the enormous ratio between the speed of CPUs and the disk bandwidth, reading a smaller file from disk and expanding it on the fly is frequently the fastest solution, so your "on-the-fly" approach seems good, and the disk space savings is probably a good "win". Thanks for the explanations. Richard A. Fowell (fowell@netcom.com) http://dmoz.org/Games/Board_Games/Chess/Software/Macintosh/
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.