[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mozilla-rhapsody
Subject:    RE: Whats Happening???
From:       Bill Bumgarner <bbum () codefab ! com>
Date:       1998-06-25 14:40:55
[Download RAW message or body]


On Fri, 26 Jun 1998, van der Stock, Andrew wrote:
> The current Mozilla Win32 backend is already probably debugged and
> optimized to near an inch of its life, presents pretty much the same API
> to the FE's. It uses Async I/O and threading to maximize performance.
> We'll be using the non-pthreads threading model on Mach/BSD ports, so
> the reality is that the Win32 backend will be more efficient with native
> code and no emulation or thunking. 

And whatever differences exist in the API can be hidden by a very thin
compmatibility layer in the object model....
 
> I don't see the need to reinvent the wheel, just re-jig it a little.
> Even so, YB/Win32 would still be slower than the eventual Win32 Mozilla
> 5.0 except that it will be nicely portable. PDF/DPS is slower than GDI,
> especially since GDI is almost the native acceleration interface for
> most modern PCI and AGP cards (trust me on this one... I helped do the
> XFree86 Matrox driver).

Actually, DPS is going away as the display model in YB.  It is to be
replaced by a 2D API that sounds similar to the 2D api in Java.

Regardless, the actual blasting of bits to the screen is a very small part
of the overall performance issues in a browser.  There are numerous much
more significant bottlenecks such as effecient I/O and properly
constructing the layout engine.  The layout engine is the killer, really--
it has to be fast, yet it also has to deal with the fact that layout
cannot often be fully accomplished until AFTER ALL of the images have been
downloaded.   The Netscape 4.x layout engine SUCKS for complex tables....
drawing speed has nothing to do with the problem.

As well, DPS offers a couple of features that greatly improve apparent
speed and hugely improve the aesthetic quality of the display.  The fact
that it supports off-screen buffers and doesn't necessarily require an app
to redraw when a window is uncovered in itself is a huge improvement over
the totally crappo WIN32 style of updating windows.

b.bum

[prev in list] [next in list] [prev in thread] [next in thread]