Subject: Re: New web page is slow

From: [email-masked]
Date: Thu, 1 May 2003 13:16:58 +0200

On Wed, Apr 30, 2003 at 05:36:11PM -0400, Bob Woodside wrote:
> On Wed, 30 Apr 2003 17:21:52 +0200
> Dominik Vogt <[email-masked]> wrote:
> 
> > On Wed, Apr 30, 2003 at 04:26:54PM +0200, Uwe Pross wrote:
> > > 
> > > On 30 Apr 2003 at 14:29:16 +0200, Dominik Vogt wrote:
> > > > The page is initially displayed with the "window" using all the
> > > > available page width.  When the pager frame is loaded, the window
> > > > shrinks to make room for the pager.  I don't see it with mozilla
> > > > 1.2.1 here (fast connection), but with 1.0 on my ISDN line.
> > > 
> > > I think this can be hardly avoided with gecko. Netscape4.x
> > > starts render the table if it got all image and text
> > > information this avoids the layout change you described but
> > > displays nothing until all contents have been loaded.
> > 
> > > Gecko starts rendering even it has not all information. 
> > 
> > Yeah.  I would think choosing a clever order of the components
> > lessens that problem.  Maybe an invisible placeholder for the
> > pager first?
> 
> 	Dominik, did the change I committed earlier today alleviate the problem
> of the pager frame resizing?

No, that did not help.  But the pager has recently become wider
again.  The width to height ratio is now 2:1.  I'm not sure if it
was your commit that caused it.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Uwe Pross <[email-masked]>
Date: Thu, 1 May 2003 13:43:54 +0200

Hi there,

On 30 Apr 2003 at 17:21:52 +0200, Dominik Vogt wrote:

> > Maybe I am a bit slow today but I don't see any coherence
> > between a couple of small image files and a performance
> > penalty (if there is such a thing).
> 
> One big file = small overhead = little performance penatly
> Many small files = big overhead = ??? performance penalty

Okay, I have thought in totaly wrong direction ;-)

For each picture one http request and one answer is needed.
This means your computer has to send one IP packet and it
has to receive _at least_ one IP packet for each file. It
will receive propably more than one packet since if your are
on an ethernet the maximum transfer unit (MTU), which is the
maximum size of an IP packet, should be set to 1500
bytes. This is the size which can pass the ethernet
connection directly. If the MTU is set to a larger value the
overhead is even more.
The IP4 header is between 20 (very likely) and 60 Bytes in
size, which gives a relation to the data to transmit of
about data/overhead = 75..25 on large files. The pager icons
are between 200 and 1000 Bytes in size which gives a data
overhead relation of about 50..3 (worst case - 60 Bytes
header and 200 bytes data).   

I think http and lower network layers as ethernet do not
have a big overhead - but I am not that sure :-)

> > Have you checked the render times by using a local version
> > of the web page? You may save the web page with mozilla and
> > load it again afterwards.
> 
> I'd have to learn how to set up apache first. :-(

Not really - To check this you can store the pages and its
images with 

wget -r --level=1 --relative --no-parent \
     http://www.fvwm.org/index.php \
     http://www.fvwm.org/pictures/decorations/window_deco_simple_steelblue/

This downloads about 700 kB which includes index.php and all
relative liked pages. The additional window decoration is
needed since wget does not obey to css definitions. 

wget should put it to the local directory ./www.fvwm.org/
from where you can load index.php in your browser. If your
browser does not know what to do with file extension .php
you might need to change is to html.

> Yeah. I would think choosing a clever order of the
> components lessens that problem. Maybe an invisible
> placeholder for the pager first?

Bob made a workaraound which might lessen the problem. But I
don't think much since as he said the problem is that the
pager contains text which size depends on the user's browser
settings.
Another possibility would be to use one ready (generated)
picture for the whole pager. Links could be declared with a
image map. Currently this is not supported by the navgen
concept at all and would make hilighting pages difficult. We
might think about if and how this could be done using the
current concept.

Regards, Uwe
-- 
  ,_,  Uwe Pross
 (O,O) mailto:[email-masked]
 (   ) http://www.tu-chemnitz.de/~uwp
=-"-"-================================
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Thu, 01 May 2003 08:32:22 -0400

> header and 200 bytes data).   

In most cases, the client has the image already cached.
In that case, the client (browser) sends about 550 bytes to
the server.  Those 550 bytes include the timestamp of the image.
The server responds with about 100 bytes indicating that the
timestamp hasn't changed.

Thats about 650 bytes per image regardless of the image size.

The slow part is not in the data itself, but in the delays between
sending and receiving.

>      http://www.fvwm.org/pictures/decorations/window_deco_simple_steelblue/

I'm not sure what you are recommending.

On my mandrake system I just installed the apache rpm.
It left a "httpd" daemon in /etc/rc.d/init.d.

php was enabled by default.
I could then access the new php pages by using

file:/home/xxxx/index.php

in the broswer.

On my home system I don't want to run httpd by default so I just
moved the httpd script to /usr/sbin.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Thu, 1 May 2003 11:37:39 -0400

> > > > available page width.  When the pager frame is loaded, the
> > > > window shrinks to make room for the pager.  I don't see it with
> > > > mozilla 1.2.1 here (fast connection), but with 1.0 on my ISDN
> > > > line.

> > 	Dominik, did the change I committed earlier today alleviate the
> > 	problem of the pager frame resizing?
> 

	Yes, it did. I made it a little too wide, and I'd like to try making it
a little narrower. I'm also going to try specifying the width for the
parent cell in the top-level table, which may help (I just noticed that
it had a width of 1% specified, which could encourage a browser to
indulge in a bit of overly agressive rendering while waiting for another
chunk of HTML to come across a slow line). We may want to back the
change out altogether, but I'm not sure yet.

	I committed this change a few minutes ago, and it has now propagated to
the live Web site, so give it a try.

	Does anyone else see the problem you're having (the resizing, not the
wider pager)? I can't make it happen no matter which browser I use. I
don't have a 1.0 Mozilla, but I do have an old 0.9.8 version lying
around, and that works fine (but that's over my cable connection, I
can't access a slow connection with that machine). The only really slow
connection I have access to is an AOL dial-up, and that doesn't resize.
Of course, AOL uses IE for its browser, so that doesn't tell us much
about the Gecko derivatives on a slow line. But it's slow enough to see
the page rendering begin, the empty pager frame appear at the proper
size, the text in the main "window" frame rendered, and then the images
start appearing in the pager - without the pager resizing. This is
exactly the way it's *supposed* to happen.

	Does anyone else have access to a slow connection and a browser other
than Internet Exploder? If so, would you try out the pages and let us
know if you see the resizing problem Dominik describes?

Cheers,
Bob

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 1 May 2003 17:55:21 +0000

On 01 May 2003 11:37:39 -0400, Bob Woodside wrote:
> 
> 	Does anyone else have access to a slow connection and a browser
> other than Internet Exploder? If so, would you try out the pages and
> let us know if you see the resizing problem Dominik describes?

I always saw this, even using localhost after a complete reload.
Opera, Konqueror. This happens now too.

I don't call this a problem, it is nice fast browser rendering engines.

As for the pager it is still too wide, the width should be 80, not 100.

Regards,
Mikhael.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 1 May 2003 16:09:04 -0400

On Thu, 1 May 2003 17:55:21 +0000

> Opera, Konqueror. This happens now too.

	I really hate to ask this...but are you absolutely sure the browser
isn't pulling a cached copy? If you view the source you should see 2
occurrences of 'width="100"'. If that's the version you're getting, and
if you see what Dominik described - not just a little resizing, but the
"window" frame rendered to fill the whole window and then resized to
accommodate the "pager" frame - then I don't know what more we can
do to try to prevent it (other than maybe making the whole pager an
image-mapped image, but I agree with Uwe in not liking that idea too
much).

	But I still can't see it happen here with NS 6.2 & 7.0, Opera 6 & 7,
IE6, Mozilla (old)...

> I don't call this a problem, it is nice fast browser rendering

	I don't think so. I still say it's over-aggressive if the browser
starts rendering a row of a table without waiting to see if any of the
cells specifies an explicit width. Redrawing the window after it
dicovers its layout assumptions were wrong slows things down, it doesn't
speed them up. Starting to render while images are loading is fine, but
not before at least getting the HTML description of the cells in the
first row. These days more and more HTML authors (and authoring tools)
have caught on to the trick of explicitly specifying image dimensions
(and cell dimensions where they think it matters, often to excess), so I
think that the likelihood of the browser's guessing correctly is
overshadowed by the likelihood that it will receive explicit layout
information in the HTML row and cell description.

> As for the pager it is still too wide, the width should be 80, not

	In theory, yes. But here again, we're at the mercy of the individual
user's browser and the fonts that it uses. On my system, 80 will be just
a bit too narrow for the page heading "Documentation"...so the browser
will go ahead and take 100 anyway. On your system, 80 is presumably just
right. That's why I don't like to specify absolute widths (except for
images) unless it's absolutely necessary. As I said, we may want to back
the fix out altogether if it doesn't produce the desired results.

Cheers,
Bob

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 1 May 2003 21:39:17 +0000

> image-mapped image, but I agree with Uwe in not liking that idea too

Since it seems you are very interested, here is the story for you.
Just tried in Konqueror 3.1 (slashes help to gets a new html copy).

  http://localhost/////fvwm-web/  # or http://fvwm.org/////

During the first such try the resizing usually does not happen.
Now I add one more slash. The window decorations occupy the whole page,
then are shrunk by a pager. Add additional slash and press Enter,
the same resizing.

With Opera currently I can't reproduce the resizing, it may be because it
is too fast or because you added the width of the parent table in the
last commit. But I can easily reproduce the layout changes. For example,
with some browser size, I see a scrollbar is added at some point and the
whole page is rendered as if there is a scrollbar, but then scrollbar
disappears and the whole page is resized to the right because of this.
Additionally, I see that the margins between the pager and the top-right
page corner are large initially and then they are reduced and the whole
pager is moved and the window decorations are resized. This is probably
because css is now in separate file and Opera starts to render without
loading the css. Anyway, it is all pretty fast and not very disturbing.

Tried several more times with Opera, it returned, I consistently see the
initial window resizing from the whole page in the NEWS page (the tall
window is rendered before the pager cell). Yes, the html has two "100".

I don't think we should do anything about this. Just get used to the idea
that the web page rendering is nowaday less static, more dynamic.
Of course if someone can improve the situation without breaking something
(like changing pager's ratio or making it look better with some fonts,
but worser with others), he is welcome.

Regards,
Mikhael.

---

From: Uwe Pross <[email-masked]>
Date: Fri, 2 May 2003 14:29:21 +0200

Hi there,

On 01 May 2003 at 13:16:58 +0200, [email-masked] wrote:

> No, that did not help.  

How about the current version? I have "reserved" a width of
80 pixels for the pager which may lessen the prob. 

Regards, Uwe