Code escape: Gzilla 0.01

[Raph Levien <raph acm org>]

Hi gtk people,

   After a couple of weeks of hacking, I am eager to show an early
prototype of gzilla to the world. Well, ok, only to gtk developers for
now, at least until the UI gets a lot smoother.

   The code is available at http://www.levien.com/gzilla-0.01.tar.gz .
It is only a 30K download, and will probably only take a minute or so to
build.

   Here's a very rough outline of the architecture:

   In gzilla, the display of a file is handled by two separate, but
linked objects. The first is what I call a "bytesink." It's main purpose
is to implement a "write" method for writing bytes into the object. The
write method typically parses this input and passes it on to the second
object, which is a gtk+ widget.

   One reason I did this is so that I could reuse existing gtk+ widgets
when applicable. For example, for gif display, the widget is just a
gtk_preview. The gzilla_gif object is basically just a
progressive-rendering adaptation of giftopnm.

   HTML page rendering is also split in two in this way. The bytesink
(gzilla_html) handles the HTML parsing, and hands words, spaces,
linebreaks, attributes, and embedded widgets to the gtk_page widget,
which takes care of the actual formatting (including word wrapping) and
display. The interface between gzilla_html and gtk_page is actually
pretty simple. Of course, that's partly due to the fact that the text
formatting is not very rich yet.

   In general, I've tried to follow the gtk+ architecture very closely.
The gtk_page widget configures itself to be the size of the page. It's
displayed in the toplevel window simply by putting it into a
scrolledwindow.

   After having gotten this far, I'm having mixed feelings. In the fully
modular widget design, gtk+ simply cannot guarantee me the performance I
feel is necessary for a really cool Web browser. The main problem I'm
running up against is size changes. In _addition_ to the problems I
mentioned a few days ago (that come into play when you put a lot of
widgets into a gtk_page), doing a gdk_window_move_resize is causing the
entire window to be blanked. I _think_ it's the underlying X server
(XFree86 3.2 on an S3 in my case) that's doing this, but I'm not
positive. Either way, it's unacceptable - instead of smooth display when
a page downloads, it flickers like <BLINK> on methamphetamines. Not
good.

   I do see a few ways around this - most notably, I could suck the
scrollbar into the gtk_page widget, make gtk_page itself a fixed size
window, and handle all of the size changes and scrolling inside gtk_page
itself. But this has two drawbacks - first, I lose modularity within the
gtk+ framework, and second, I have to repaint the entire window on every
scroll. The way it works now, scrolling causes most of the window to be
preserved, with an expose event for the little bit that scrolled into
visibility. I'm pretty sure this is the approach that Netscape uses, by
the way.

   Another possiblility is the way qweb does it - throttle the rate of
window resize calls. This way, the flashing is reduced (so it now looks
like <BLINK> on barbiturates) but not entirely eliminated. Also, updates
don't appear to happen as quickly.

   If gzilla is to be used primarily to browse local files (e.g. as the
Gimp's help browser), then the window flashing problem is not nearly so
severe.

   So please take a look and let me know what you think. If you have any
ideas about the window flashing problem, I'd certainly like to hear
them.

Raph