JTK wrote: > > jesus X wrote: > > > > Your constant mentioning of this is quite illogical. All SGML based technologies > > (HTML, XML, etc.) are "interpreted ASCII" text. > > Right. All program GUIs are not SGML based however. In fact AFAIK none > are except for Mozilla's.
[snip] > No program's UI is. Except Mozilla. Er, wrong. GNOME uses libglade for many apps (xml-based). Visual basic programs use .frm files (text based!). I'm pretty sure .NET's Windows.Forms package is similarly text-based. KDE has an xml-based UI solution in development too, I believe. > Wrong. That's *compiled* ASCII text. And don't try to tell me you > don't know the difference, but do try to explain why you think you need > to try to fool somebody here in such an ameturish fashion. So you're telling me that your argument is completely obsolete now that FastLoad is implemented and the XUL/js is now compiled? Great! Then you'll be shutting up about it any minute now, right? > Right, nothing wrong with a complied GUI. Plenty wrong with an > interpreted GUI. See above. > > Mozilla's use of XML for it's UI language > > Why does a UI need a "language"? I don't want my browser buttons to do > anything but push and do what they say on the label. Um, and how do you propose to specify those buttons without a language? Even Button button = new Button(0, 0, 60, 20, "My button"); is still a "language". It's just a very inflexible one. > > adds a truly insignificant amount of > > processing overhead, especially when compared to the increased portability it > > introduces. > > If it were "truly insignificant", you wouldn't need to qualify that with > "compared to the increased portability it introduces." It'd swim on its > own, wouldn't it? Well, the original poster's point was that it doesn't *need* to swim on its own, because it confers other advantages. Portability is just one of those. Another is the fact that, compared to the "Button button" style code above, you don't have to manually change the coordinates of all the other buttons in your application when you add a new one in front. Another is that hundreds of people *are* offering code fixes to Mozilla despite not knowing C++ because the fixes can be implemented easily in simple languages that are very approachable. So EVEN IF I were to grant your point that XUL adds unneccessary overhead, I would *still* claim that XUL is worth it. In fact, I do grant that there is some overhead due to XUL. Even when it's compiled by the fastload system into fast native code, and even when it results in drawing real, native widgets (0.9.8 classic skin will support this on WinXP, I believe). Mostly the overhead is in terms of memory usage rather than speed, but it's still overhead. But this is *implementation* overhead, and isn't fundamentally necessary. And that's why your comments below about the XUL cache are just patently stupid. If XUL was fundamentally bad, as you claim, then it wouldn't be *possible* to enhance it's performance by using a XUL cache. It wouldn't be *possible* to use fastload to compile it into fast native code. It wouldn't be *possible* to optimize it to the point, as it is now, that page load times beat (native UI-based) Netscape 4 by a factor of at least 2 or 3 (see a post by hixie several months ago; page loads have improved substantially even since then) even with the supposed 15% "XUL overhead". > So it's "truly insignificant", but somebody figured an "XUL cache" was > necessary anyway. Who's kidding who here rabbi? See above. > Prior to this "XUL cache", or subsequent to it? And you of course have > the numbers to prove it? The 15% number is a red herring. I guarantee you that any of Mozilla's chief hackers could produce a XUL-based browser in which 0% of a pageload time was dedicated to XUL - by not repainting or updating any progress meters, disabling or enabling the stop button, or animating the throbber during pageload, adding the page to the back/forward memory as appropriate, etc. And if you do all of those things in a native interface, they'll cost you some time too. Whether that amount of time is greater or less than 15% depends on the speed of your native toolkit and how fast your page rendering time is, and also how much user responsiveness you're willing to give up while loading pages, but from what I've heard many of Mozilla's native wrappers aren't substantially faster at pageload than Mozilla itself anyway, which would suggest that 15% is about right for both types of browser. The user responsiveness issue is also vital; one of the reasons I prefer Mozilla to IE is that whenever I use a computer with IE installed, it goes to its homepage by default and is extremely unresponsive during the time that page is loading - I have a hard time pressing "stop" in that period, usually. With Mozilla, they sacrifice a part of that 15% "UI time" during pageload to make sure that the stop button, and other user interface items, remain responsive while pages are loading, and in my experience they do substantially better than IE at this. I'd gladly sacrifice 5% of the very small amount of time it takes to load a page in exchange for being able to press stop, or back, or choose a bookmark, or switch tabs, in the interim and have the browser actually respond. > > Not that 15% of a fraction of a > > second is anything to complain about to begin with. > > And do you recall the memory overhead? Sure, the memory overhead is substantial. Would you have liked them to work on the memory overhead (which can be addressed by buying a little more memory) or the speed overhead (which can't be addressed without replacing your processor) first? The speed overhead is now down to levels which are acceptable on almost any computer with sufficient memory (I challenge you to test this - I bet that you cannot find a browser operation except for window opening that Netscape 4 performs more than 20% faster than Mozilla on any machine with 256Mb of RAM or more... and I'd almost be willing to make the same bet for 128Mb. I'd also bet that the vast majority of browser operations are already substantially faster in Mozilla. Mail and news aren't there yet, but they've generally lagged the browser by about 6 months, so they should be there soon; window opening is an area that still needs work - and is getting it.) The memory overhead has been gradually decreasing over the past few months also, because work is being done in this area. While most of the developers are focused on speed issues, there have been big memory leak fixes and data structure improvements that have cut memory overhead too. As the speed is getting closer and closer to where it should be, more and more effort will be devoted to achieving the same thing with memory usage. I don't know whether Mozilla will ever be a great performer on 32Mb machines, but I'm sure it will be great on 64Mb machines within a year - despite *more* features being added to it in the interim. > Like the cache? I beat that drum. Like the news editor? I'm pretty > vocal about that too. What say you AOL should fix, Lord? Well, that seems to me to be a pretty good reason not to waste time rewriting everything from the ground up without XUL, doesn't it? There's plenty of other things to work on, as you admit. Stuart. -- Stuart Ballard, Programmer FASTNET - Internet Solutions 215.283.2300, ext. 126 www.fast.net
