I think Chris is a bit sent astray with all the things happening in the
market, like Intel saying 'you really need a PIII to surf the net'.  Duh...
rendering time on my 386 laptop with Win95 installed is still very fast.
Don't forget we're talking the web here.

HTML - SIMPLE markup language without scripting capabilities
IMAGES - Low-res low-color low-size compressed pieces of bits

It's inferior to anything else happening on PC's nowaddays.  My God, I have
a digital video editing card and my PC spits out 7.1MB and 25 frames a
second with 24bit color at 768 x 576 pixels.  Guess that's somewhat more
difficult than displaying a lousy gif image with 256 of size 200 x 150 on a
website.

Rendering comes into performance-play when you start with difficult tasks
like PDF (notice how a document builds up?) or flash (notice how some
computers just can't handle all those gradients that are moving and resizing
and exploding and morphing?).

Rendering is not a big issue when working on pixel-based (bitmap) elements.
There's mainly one thing that doesn't fit within this story: text.  Text is
vector, but whatever, it's a tiny 40k file that's cached in memory, on the
harddisk, and is the core thing in any OS (even DOS).

Conclusion... unless you're surfing on that RadioShack AT PC you bought back
in '79, don't worry about rendering times.  Go play a few 3D games.  You'll
know what I mean.


- Kayjey -


-----Oorspronkelijk bericht-----
Van: owner-hwg-techniques(at)hwg.org
[mailto:owner-hwg-techniques(at)hwg.org]Namens Larry Coats
Verzonden: vrijdag 15 juni 2001 2:55
Aan: Chris Hawkins
CC: hwg-techniques(at)hwg.org
Onderwerp: Re: Tables loading question




Chris Hawkins wrote:

> Regarding download wait on tables.
>
> Dilemma is that we need one main enclosing table to fix the overall width
> and put percentages in the nested tables to control the page width.  My
> boss is adamant about download times, but i am arguing for a relatively
> fast compromise, but I need your input on how tables download.  I realize
> the browser must load the main table first.
>
> Got 4  questions:
>
> 1) Is it less time to load a one row, one cell table than one with
multiple
> rows and cells?
> 2) Would the next download after the big table,  be the first nested table
> at the top, that's within the one big cell? (then the next and the next
etc.)
> 3) What exactly is the browser interpreting  -- the table tag structure or
> every single thing in the table?  Does that have a specific weight in
itself?
> 4) and HOW do i test something like this?
>
> My thinking was that a one-cell one rowed table would take less time than
> one with  multiple rows.

I can't agree with your thinking. It may take the browser a little less time
to
figure out how to lay out the one-cell table once it has all the
information, but
my gut feel is that the time it takes to amass the information is a lot more
important that the time it takes to lay out the information once it's
arrived.

Let's begin with question 3. The browser is reading the HTML file from the
top
downward. It doesn't try to skip around, it goes through a byte at a time,
in
order.

When it hits a <.table> tag, it has no idea how many rows, columns or cells
there
are going to be.

When it hits the first <./tr> tag, it knows how many columns there are in
the
first row. It can make an educated guess that all of the rows will have the
same
number of columns (after taking rowspans and colspans into account, of
course),
but it's not absolute: I know I've accidentally created a table in which
most
rows have, say, seven columns but one had eight or nine. So the browser
can't be
sure how many columns there are, and of course it has no idea how many rows
it
has, until it reaches the <./table>. So it really can't begin placing things
on
the screen until it gets to that <./table>, at least not without the risk of
having to move things around later. Even if you've specified widths for the
columns, it can't be sure it can honor those. Just because you say a column
is
100 pixels wide doesn't prevent you from putting a 150-pixel wide image into
it,
and the browser has to be able to adjust for that.

If you've religiously (or even atheistically!) provided width and height for
all
of the images in the table, the browser knows everything it needs to know to
lay
out the table once it reaches the <./table>. That's the single most
important
thing you can do. If you omit any of these, the browser can't finish
deciding how
to lay out the table until those images have been downloaded, and it'll seem
to
take much longer for the page to display. Especially in Netscape 4, which
needs
everything cast in concrete before it sees daylight on your screen -- IE
will
sometimes go ahead and start placing things, and move them around later if
it has
to. Which can be irritating to your users.

Let's see, I think I've answered question 3 and probably question 1.
Regardless
of whether there's just one cell or more than one, the browser can't know
that
until it reaches <./table>, so it can't start laying it out until then. Like
I
said, it now might be able to lay out a single-cell table a bit quicker, but
unless the table is really complex, I don't think this stage takes anywhere
near
as much time as retrieving the HTML code for the table.

Question 2 I've already answered too, I think -- it's reading through the
HTML
file in sequence. When it finds a nested table, it has to go through that in
its
entirety before it gets back to processing the rest of the outer table. And
it
has to be able to figure out the layout for that before it can lay out the
outer
table. And this could get pretty complex, because the layout of that inner
table
can depend on the layout of the outer table. For example, if your outer
table
consists of just two cells side by side in a single row, and if each of
these
cells contains a nested table, the width of each cell is affected by the
width of
the other and the browser has to somehow decide how to size each of the two
nested tables so that they can best fit side-by-side, honoring your
requested
widths (if any) but feeling free to override those if it feels it has to
(browser
have feelings???).

Given all that the browser has to take into consideration, I suppose the
"think
time" could get fairly long if the table and nested tables are really
complex.
Which brings us to question 4: how can you test all this? Sorry, I don't
have any
good ideas off the top of my head.

Larry Coats

 

• Web Designer Courses
• Off the Shelf Training Courses

HWG hwg-techniques mailing list archives, maintained by Webmasters @ IWA