Full Article Attached Mail/News Performance Effort Underway

Friday November 2nd, 2001

Seth Spitzer today sent an update out about what the Mail/News team is doing to meet their goals for Mozilla 1.0. They'll be focusing almost 100% of their effort for at least the next two milestones (0.9.7, 0.9.8) on Footprint and Performance of the various parts of Mail, News, and Addressbook. Not only will they be focusing on it, they'll also be locking down their part of the tree and only accepting performance or footprint fixes. Very few exceptions will be made. Click the Full Article link to see Seth's full post.

#191 Re: Re: Re: Re: Re: Re: Re: please

by roc <>

Friday November 9th, 2001 9:44 AM

You are replying to this message

> The system hands the event to the application first. <

So on Windows you want to capture the messages in the GetMessage()/DispatchMessage() loop, run the Web page's Javascript in there, and use the results to futz with the messages before dispatch? Do you have any idea how error-prone that would be? Do you have any idea what Windows might do if the Web page decided to (for example) cancel all the mouseup (but not mousedown) messages for a control? Plus it simply won't work if Windows decides to SendMessage() some of the messages you need to capture.

> Background images _in_ widgets is not a CSS feature.

That is technically true, but people do it and IE and Mozilla support it. (CSS borders on edit controls get used a lot.)

> Widgets are drawn in a z-ordered fashion on both Mac and Windows. <

True, but their z-order support is not sufficient for our purposes. Suppose I have a text element (with transparent background) that the Web page author has positioned overlapping an edit widget, and above the edit control in the z-order. How would you render this with native widgets in Windows?

> Please note, however, that overlapping widgets is almost always a design mistake. <

Tough luck, Mozilla still has to render it right. Welcome to the real world.

> Clipping is fully controllable through the GrafPort or drawing context. <

On Windows (dunno about Mac) you can't clip native widgets this way because you don't get to set the clip region on their DC when they paint. (How much do you really know about Windows programming anyway?. VB doesn't count.)

> However, please note that clipping to only part of a widget is also a design mistake ... Clipping out the whole thing is fine, and trivial to do. <

That would not be "fine". Mozilla has to render all pages correctly, even if the results are ugly.

> If you have translucency, you have to draw to an offscreen pixmap in layer order, but that's the same with or without widgets, and has long ben a standard drawing mode on both platforms. <

Do you have any idea how hard it is to get a Windows native widget to render into an off-screen buffer, or anywhere except the screen? The code that tried to do this for Netscape 4 printing (with less than complete success) was sprinkled with nasty comments about "Jedi mind tricks". If you think this is so easy, show me some sample code that renders a simple Windows edit control into an off-screen buffer. Please use only documented Windows APIs.

> Anyhoo, I don't see what's faster about creating 500(!) XUL widgets as opposed to native widgets. <

Well, for example, on Windows 95/98 this would probably hang your system by running it out of "System Resources".

> Text editing is a special case and most applications do roll their own when they have to do this kind of thing. <

Ah, HERE we go. If you're going to do your own text editing, which is the most complex widget by far, then you might as well go the whole hog.

> In fact CSS3 rerquires using the platform standard appearance. <

I think not. Citation?

> Microsoft does use native widgets in IE <

WinIE 5.x certainly does not (I haven't tried IE6). Just fire up IE, bring up a page with text edit controls, and use Spy++ to try to select the native edit controls in IE's window. You can't because they're not there.

> and they support more than one platform. <

MacIE is a completely separate code base from WinIE, so having WinIE use Windows native widgets wouldn't have created any cross-platform coding problems.