Fast computers are still needed if you're actually using them for work...
Just as an example, compiling+linking a nontrivial program with profile-guided optimization (say Firefox) using MSVC++ takes several hours on decent modern hardware. I'd love for that to happen in, say, seconds instead.;)
> Just use the build number in the registry key name.
Build numbers are not globally unique.
It sounds like you're running the app by double-clicking the shortcut and the shortcut just points to the executable. If you change the shortcut to pass in a profile name, or run the executable with the appropriate arguments from the command line, and use different profiles for different installs, it all works.
> Your first purpose could be just as easily done with the registry. > Separate installs, separate keys...
That would mean having to change keys every day, to make it work with nightly builds.
> Personally, I'd like to see the ability to have more than one installation of Firefox > actually running simultaneously.
You already can, by having them use different profiles (and should, since moving from newer to older versions in the same profile might not necessarily work so great).
I can't speak to Firefox Portable; I'm not at all familiar with the details of how it works.
1) Allows easy side-by-side install of multiple Firefox versions (including multiple
nightly builds). 2) Allows easy uninstall by deleting the install directory without having to rely on
resetting registry values correctly on uninstall.
The difference between Chrome and Chromium is the same as the difference used to be between StarOffice and OpenOffice, or as the difference between Netscape and Mozilla was back when Netscape still existed. Chromium is an open-source project. Chrome is a product built on top of that project; one that may have restrictions on it that the source itself does not have.
That's Chromium. It does not include ffmpeg. Chrome (which is not quite the same thing) does, and Chrome cannot in fact be redistributed without OK from Google last I checked.
> do you feel we should have a longer term goal over and above HTML5
Yes.
> I do not personally see any urgency in getting a new spec out there when we have XHTML1
XHTML1 doesn't actually define browser behavior sufficiently to allow interoperable implementations to be built based on it. I'd say that this lack has been the biggest barrier to entry in to the browser market for the last 10 years or so.
> which is extensible enough
The point is to extend the same way in multiple browsers, which means having a spec for the extensions. You seem to feel that this spec should not be called HTMLn for some n. I really don't care what it's called much; I care about the substance.
> I do not feel HTML5 actually brings anything to the table.
It brings to the table an actual specification for how to deal with text/html input; something that's never existed before. It defines the interaction of things like document.write and HTML parsing. Just that on its own is worth publishing a spec (and there are those who feel that this is all HTML5 should do, mind you).
Now it also brings along some features. I couldn't care less if the features got spun off into separate specs, as I said. And some of them have been, and more will be.
But I'm not sure how you can say that, say, is any less something that should be done in "HTML" than is...
> Because defining a specific standard for a media format puts us in exactly > that situation.
It would, if that happened. But it's not happening, and no one has suggested it. There have been suggestions to require at _least_ Theora support, with no restrictions on what else can be supported. No one is proposing forbidding other codecs or anything silly like that.
It's good to have your facts straight when critiquing things.
> This is not simple, simplicity means having the most simple, straightforward way of doing > things and that's having one way.
This is true, and HTML5 does this as it can, within the design constraint of being compatible with existing web content. Unlike HTML4, it defines a single way of parsing documents, for example.
But the reason I pointed to that link is because it does a good job of explaining the networking effects via which a "good enough" thing can displace a "good" thing if the "good enough" ships first. This is exactly what's happened with HTML and XHTML and why consistency with HTML is now needed in whatever markup language the web ends up using.
Fair points on most (though a lot of work has gone into the sound sync issue since the last beta; I'd be curious to find out how the rc does for you when it comes out). But the overlays issue is not that simple. If you just want to render video to screen, they're the way to go. If you want to allow your video to play nice in your HTML+SVG+video webpage (e.g. applying SVG color filters to the video, or svg masks, or CSS transformations, etc, etc), then overlays no longer cut it. You can do it with 3d graphics, and there are plans to move to GL for a bunch of this stuff in Gecko. But that's its own level of fun, especially on the devices where it really matters (handhelds of various sorts), where 3d hardware is just appearing.
> Why not wait until the standard is "up to par" with the likes of Microsoft's > Silverlight or Adobe's Flash?
Because sometimes shipping a "good enough" product might be better than waiting till it's "perfect". For various values of "good enough" and "perfect". What constitutes "good enough" varies for different people, of course...
If the question is why Mozilla is not shipping H.264, it's because the patent licensing would make it impossible to ship it in Firefox while continuing to make all the source of Firefox open in the sense of anyone being able to build a browser from the source and distribute it.
Note that this last (not having everything open) is the approach Chrome has taken: the open-source Chromium has not H.264 support. Chrome ships an LGPL library in addition to the Chromium code (ffmpeg) that does H.264 decoding but that you then can't redistribute as part of a product without getting your own patent license.
Put another way, Mozilla is doing what it's doing so Debian can keep shipping IceWeasel without having to negotiate a patent license to have feature parity with Firefox.;)
> I'm referring to the fact that you can't count on HTML5 documents being well formed > like you can with XHTML.
While true, that doesn't matter that much if the parsing algorithm is well-defined. And the current problem is that you can't count on any documents actually being produced as XHTML (with the right MIME type; there's plenty of stuff out there with the XHTML doctype, and most of it is not well-formed).
> All for the sake of people being able to write sloppy markup
They already do this, and are enabled by the fact that web browsers "deal". The parsing specification if entirely for the benefit of consumers of the crap that the producers are generating no matter what.
The other alternative is fatal error handling and all consumers sticking to their guns on that (which even for XHTML they're not so much). As you note, XHTML tried this approach. It failed in the marketplace, for various reasons, ranging from lack of IE support to it being too much pain to author with the tools people were using.
> Imagine if the JPEG format had been forced as the only format leaving no scope for > animated gifs?
Then that would be a poor standard. I don't see what that has to do with the HTML5 draft.
> WHATWG is a group that was setup by individuals, which is a far cry from the W3C > which as you rightly state is quite well represented.
Not quite. WHATWG was set up by individuals officially representing Opera, Mozilla, and Apple. The W3C is a pay-to-play industry consortium. Both take input from various sources, but in the end for WHATWG the steering committee has members from the above three organizations and for the W3C the consensus need only be amongst the paid-up members. Which is better for the web depends on whether you trust the above three organizations to develop web technologies more than you trust the average W3C member...
> The W3C was on the right path
Do you mean not having made any meaningful progress on actually delivering anything other than a recasting of HTML4.01 into XML syntax in years? Or do you mean having made some progress on defining a completely new language that would be incompatible with both XHTML1 and HTML4.01 and that had no clear strategy for how anyone would actually start using it?
Note that nothing prevents work on XHTML2 from continuing. It would hardly be the first time the W3C has produced specs that don't work well with each other, or even flat-out contradict each other.
Note also that HTML5 does have some serious issues on a lot of the details; those need to be worked out. But the overall approach of something that can actually be adopted incrementally seems to be the correct one to me. It's already paying off: the web platform is moving forward for the first time in years, and might even stave off the Silverlight-like beasties.
http://dbaron.org/log/2006-08#e20060818a (which explains more or less how some of the people who started the WHATWG came to be working outside the W3C in the first place).
As a simple example, say that clinical trials in fact cost $800M for each drug, and that 1 in 2 drugs comes out of trials marketable (doesn't kill people, actually helps for the disease).
Now on average, someone who's developing and testing drugs is paying $1600M per drug they bring to market. Someone just buying the production rights, per the above proposal, is paying $400M for half the profits from the production.
So at that point one party has invested $1200M, the other has invested $400M, and both get the same absolute return on their investment (half the drug sales). As more parties buy in, the money is split among the existing licence holders (evenly?); depending on how this is split and how many other parties buy in maybe the original drug developer/tester might come out ok.
But pending that, the obvious conclusion is that developing and testing drugs is a sucker deal. The right thing to be doing is buying into rights on already-successful drugs.
One solution might be to set the price based on the cost of the trials that failed too.... but that gets very complicated (e.g., which particular trials for failed drugs should be included in the licensing terms for which successful drugs?).
One would think that the right way to zero memory would be memset, which happens to be portable and is presumably implemented in a very similar way, no?
This test isn't testing the speed of javascript execution, for the most part. So while Tracemonkey does speed it up a bit, it doesn't help much, because most of the test's time is not spent actually interpreting JS.
It's pretty common for a non-JS-heavy site (say cnn.com) to download several hundred KB of JS. That's a lot, for what is a pretty high-level language.... gmail and its ilk have even more.
But you're right that there are two separate issues here: performance of javascript itself (measured by things like the v8 tests and sunspider), which mostly matters for applications that want to actually do a lot of computation in their javascript, and performance of the DOM and layout engine, which matters for updating the state of the web page.
If you're trying to write an app that plays Go, say, the former is what you might care about; in this case the update is placing a stone and maybe removing some, and its cost is dwarfed by the cost of deciding _where_ to place the stone. At least if your app actually plays instead of plopping stones randomly. Similarly, if you're writing a spreadsheet, then the cost of recomputing values based on other value changes (and of keeping track of what values need recomputing, etc) probably dwarfs the cost of updating the text in the cells.
If you're writing something that just moves lots of things around on screen, or that switches between views without doing much other work (hey, gmail) or something of that sort, then DOM and layout performance is what you care about.
> Isn't most of Javascript just mapping down to a C++ library below it?
Not in something like google spreadsheets or an image editor written in JS (yes, these exist nowadays). Or if you want to have a word processor that provides its own spellchecker...
Odd how so many of the things google is working on actually do rely on fast JS.;)
Unfortunately, the benchmark doesn't publish its code, and tries very hard to prevent anyone else getting their hands on it. I spent a day or so trying to reverse-engineer their obfuscation once before I gave up. Furthermore, nowhere is there an explanation of where the number the benchmark shows actually comes from.
This immediately drops its credibility compared to benchmarks like v8, sunspider, dromaeo, or anyone else who publishes their methodology for public review. It turns out that it's pretty easy to mis-write your benchmark in such a way that its results are useless (e.g. stopping a timer before the work you're benchmarking has actually been done in a browser that does it lazily)...
If that's the usage pattern, then renting may or may not be cheaper than owning. 2-day rentals for $100 seems quite easy to do (heck, might be doable for $50 depending on what you rent; the $100 figure would likely include gas too), and if you do that every weekend that puts you at $5200 for the year. That's cheaper than the yearly cost of owning in many cases. Probably not even the majority, but many.
Of course if you only need the car once every few weekends, that affects the numbers a good bit.;)
Putting plug-ins out of process is actually simpler than what this article is about, and is being targeted for much sooner. And yes, that would help with the problem you're seeing.
No, because the shared memory model of threads means that if a thread is exploited and writes to memory that a "higher privilege" thread then reads, you lose.
The amount of code that needs changing here has actually been decreasing in a lot of cases.. You seem to assume that Firefox had a significantly smaller codebase at some point. It didn't, really, ever since the Phoenix project existed.
As for Flash, that's a separate issue from what this article is about; putting plug-ins out-of-process is not the same as splitting up browser rendering across multiple processes.
Firefox rendering is currently single-threaded. There are threads that are used for network access and some other things like that, but all the layout and painting happens on one thread.
Splitting it to happen on multiple threads is not that much less work than splitting it to happen in multiple processes, and the latter has certain stability and security benefits (e.g. _if_ there is a bug that allows a renderer process to be exploited that need not automatically mean a local user exploit). It also allows memory leaks to be controlled better. Yes, fixing the leaks is still important, but we can't fix the leaks in plug-ins (which is why those are moving into separate processes too) or third-party libraries (including the OS ones used for text measurement, say).
So this is more defense in depth than "surrender".
That's being done too. It's a shorter-term project than what this article is about.
That said, there are some issues with doing it, especially on Mac (apparently getting one processor to paint into another process's window is rocket science there).
> PPS: The article says it's 93 but I see 94 on Acid3's Wikipedia page for Firefox 3.6a1pre.
Sure; the article is about 3.5b4. 3.6a1pre has several months of development work on it that were not merged to the 3.5 branch (which was stabilizing instead).
Um... ATI Radeon 9600 cards do AGP, and go up to 2048x1536 resolution. They can most certainly drive an LCD at 1600x1200 with no trouble.
That's just off the top of my head; I happened to know that this card does what you want because it's sitting here in an AGP 4x slot driving a 1600x1200 LCD, and has been for two years now. Depending on pro vs non-pro versions, etc the price varies somewhere in the $60-200 range, I think.
Slashdot Mirror
Fast computers are still needed if you're actually using them for work...
Just as an example, compiling+linking a nontrivial program with profile-guided optimization (say Firefox) using MSVC++ takes several hours on decent modern hardware. I'd love for that to happen in, say, seconds instead. ;)
> Just use the build number in the registry key name.
Build numbers are not globally unique.
It sounds like you're running the app by double-clicking the shortcut and the shortcut just points to the executable. If you change the shortcut to pass in a profile name, or run the executable with the appropriate arguments from the command line, and use different profiles for different installs, it all works.
> Your first purpose could be just as easily done with the registry.
> Separate installs, separate keys...
That would mean having to change keys every day, to make it work with nightly builds.
> Personally, I'd like to see the ability to have more than one installation of Firefox
> actually running simultaneously.
You already can, by having them use different profiles (and should, since moving from newer to older versions in the same profile might not necessarily work so great).
I can't speak to Firefox Portable; I'm not at all familiar with the details of how it works.
> What's the purpose of not using the registry?
The two main ones that come to mind are:
1) Allows easy side-by-side install of multiple Firefox versions (including multiple
nightly builds).
2) Allows easy uninstall by deleting the install directory without having to rely on
resetting registry values correctly on uninstall.
The difference between Chrome and Chromium is the same as the difference used to be between StarOffice and OpenOffice, or as the difference between Netscape and Mozilla was back when Netscape still existed. Chromium is an open-source project. Chrome is a product built on top of that project; one that may have restrictions on it that the source itself does not have.
That's Chromium. It does not include ffmpeg. Chrome (which is not quite the same thing) does, and Chrome cannot in fact be redistributed without OK from Google last I checked.
> do you feel we should have a longer term goal over and above HTML5
Yes.
> I do not personally see any urgency in getting a new spec out there when we have XHTML1
XHTML1 doesn't actually define browser behavior sufficiently to allow interoperable implementations to be built based on it. I'd say that this lack has been the biggest barrier to entry in to the browser market for the last 10 years or so.
> which is extensible enough
The point is to extend the same way in multiple browsers, which means having a spec for the extensions. You seem to feel that this spec should not be called HTMLn for some n. I really don't care what it's called much; I care about the substance.
> I do not feel HTML5 actually brings anything to the table.
It brings to the table an actual specification for how to deal with text/html input; something that's never existed before. It defines the interaction of things like document.write and HTML parsing. Just that on its own is worth publishing a spec (and there are those who feel that this is all HTML5 should do, mind you).
Now it also brings along some features. I couldn't care less if the features got spun off into separate specs, as I said. And some of them have been, and more will be.
But I'm not sure how you can say that, say, is any less something that should be done in "HTML" than is...
> Because defining a specific standard for a media format puts us in exactly
> that situation.
It would, if that happened. But it's not happening, and no one has suggested it. There have been suggestions to require at _least_ Theora support, with no restrictions on what else can be supported. No one is proposing forbidding other codecs or anything silly like that.
It's good to have your facts straight when critiquing things.
> This is not simple, simplicity means having the most simple, straightforward way of doing
> things and that's having one way.
This is true, and HTML5 does this as it can, within the design constraint of being compatible with existing web content. Unlike HTML4, it defines a single way of parsing documents, for example.
But the reason I pointed to that link is because it does a good job of explaining the networking effects via which a "good enough" thing can displace a "good" thing if the "good enough" ships first. This is exactly what's happened with HTML and XHTML and why consistency with HTML is now needed in whatever markup language the web ends up using.
Fair points on most (though a lot of work has gone into the sound sync issue since the last beta; I'd be curious to find out how the rc does for you when it comes out). But the overlays issue is not that simple. If you just want to render video to screen, they're the way to go. If you want to allow your video to play nice in your HTML+SVG+video webpage (e.g. applying SVG color filters to the video, or svg masks, or CSS transformations, etc, etc), then overlays no longer cut it. You can do it with 3d graphics, and there are plans to move to GL for a bunch of this stuff in Gecko. But that's its own level of fun, especially on the devices where it really matters (handhelds of various sorts), where 3d hardware is just appearing.
> Why not wait until the standard is "up to par" with the likes of Microsoft's
> Silverlight or Adobe's Flash?
Because sometimes shipping a "good enough" product might be better than waiting till it's "perfect". For various values of "good enough" and "perfect". What constitutes "good enough" varies for different people, of course...
If the question is why Mozilla is not shipping H.264, it's because the patent licensing would make it impossible to ship it in Firefox while continuing to make all the source of Firefox open in the sense of anyone being able to build a browser from the source and distribute it.
Note that this last (not having everything open) is the approach Chrome has taken: the open-source Chromium has not H.264 support. Chrome ships an LGPL library in addition to the Chromium code (ffmpeg) that does H.264 decoding but that you then can't redistribute as part of a product without getting your own patent license.
Put another way, Mozilla is doing what it's doing so Debian can keep shipping IceWeasel without having to negotiate a patent license to have feature parity with Firefox. ;)
> I'm referring to the fact that you can't count on HTML5 documents being well formed
> like you can with XHTML.
While true, that doesn't matter that much if the parsing algorithm is well-defined. And the current problem is that you can't count on any documents actually being produced as XHTML (with the right MIME type; there's plenty of stuff out there with the XHTML doctype, and most of it is not well-formed).
> All for the sake of people being able to write sloppy markup
They already do this, and are enabled by the fact that web browsers "deal". The parsing specification if entirely for the benefit of consumers of the crap that the producers are generating no matter what.
The other alternative is fatal error handling and all consumers sticking to their guns on that (which even for XHTML they're not so much). As you note, XHTML tried this approach. It failed in the marketplace, for various reasons, ranging from lack of IE support to it being too much pain to author with the tools people were using.
> Imagine if the JPEG format had been forced as the only format leaving no scope for
> animated gifs?
Then that would be a poor standard. I don't see what that has to do with the HTML5 draft.
> WHATWG is a group that was setup by individuals, which is a far cry from the W3C
> which as you rightly state is quite well represented.
Not quite. WHATWG was set up by individuals officially representing Opera, Mozilla, and Apple. The W3C is a pay-to-play industry consortium. Both take input from various sources, but in the end for WHATWG the steering committee has members from the above three organizations and for the W3C the consensus need only be amongst the paid-up members. Which is better for the web depends on whether you trust the above three organizations to develop web technologies more than you trust the average W3C member...
> The W3C was on the right path
Do you mean not having made any meaningful progress on actually delivering anything other than a recasting of HTML4.01 into XML syntax in years? Or do you mean having made some progress on defining a completely new language that would be incompatible with both XHTML1 and HTML4.01 and that had no clear strategy for how anyone would actually start using it?
Note that nothing prevents work on XHTML2 from continuing. It would hardly be the first time the W3C has produced specs that don't work well with each other, or even flat-out contradict each other.
Note also that HTML5 does have some serious issues on a lot of the details; those need to be worked out. But the overall approach of something that can actually be adopted incrementally seems to be the correct one to me. It's already paying off: the web platform is moving forward for the first time in years, and might even stave off the Silverlight-like beasties.
Additional recommended reading:
http://www.jwz.org/doc/worse-is-better.html (which sort of sums up why HTML5 is getting more traction than XHTML2).
http://dbaron.org/log/2006-08#e20060818a (which explains more or less how some of the people who started the WHATWG came to be working outside the W3C in the first place).
The math on this doesn't work out.
As a simple example, say that clinical trials in fact cost $800M for each drug, and that 1 in 2 drugs comes out of trials marketable (doesn't kill people, actually helps for the disease).
Now on average, someone who's developing and testing drugs is paying $1600M per drug they bring to market. Someone just buying the production rights, per the above proposal, is paying $400M for half the profits from the production.
So at that point one party has invested $1200M, the other has invested $400M, and both get the same absolute return on their investment (half the drug sales). As more parties buy in, the money is split among the existing licence holders (evenly?); depending on how this is split and how many other parties buy in maybe the original drug developer/tester might come out ok.
But pending that, the obvious conclusion is that developing and testing drugs is a sucker deal. The right thing to be doing is buying into rights on already-successful drugs.
One solution might be to set the price based on the cost of the trials that failed too.... but that gets very complicated (e.g., which particular trials for failed drugs should be included in the licensing terms for which successful drugs?).
One would think that the right way to zero memory would be memset, which happens to be portable and is presumably implemented in a very similar way, no?
Tracemonkey speeds up javascript execution.
This test isn't testing the speed of javascript execution, for the most part. So while Tracemonkey does speed it up a bit, it doesn't help much, because most of the test's time is not spent actually interpreting JS.
It's pretty common for a non-JS-heavy site (say cnn.com) to download several hundred KB of JS. That's a lot, for what is a pretty high-level language.... gmail and its ilk have even more.
But you're right that there are two separate issues here: performance of javascript itself (measured by things like the v8 tests and sunspider), which mostly matters for applications that want to actually do a lot of computation in their javascript, and performance of the DOM and layout engine, which matters for updating the state of the web page.
If you're trying to write an app that plays Go, say, the former is what you might care about; in this case the update is placing a stone and maybe removing some, and its cost is dwarfed by the cost of deciding _where_ to place the stone. At least if your app actually plays instead of plopping stones randomly. Similarly, if you're writing a spreadsheet, then the cost of recomputing values based on other value changes (and of keeping track of what values need recomputing, etc) probably dwarfs the cost of updating the text in the cells.
If you're writing something that just moves lots of things around on screen, or that switches between views without doing much other work (hey, gmail) or something of that sort, then DOM and layout performance is what you care about.
> Isn't most of Javascript just mapping down to a C++ library below it?
Not in something like google spreadsheets or an image editor written in JS (yes, these exist nowadays). Or if you want to have a word processor that provides its own spellchecker...
Odd how so many of the things google is working on actually do rely on fast JS. ;)
Unfortunately, the benchmark doesn't publish its code, and tries very hard to prevent anyone else getting their hands on it. I spent a day or so trying to reverse-engineer their obfuscation once before I gave up. Furthermore, nowhere is there an explanation of where the number the benchmark shows actually comes from.
This immediately drops its credibility compared to benchmarks like v8, sunspider, dromaeo, or anyone else who publishes their methodology for public review. It turns out that it's pretty easy to mis-write your benchmark in such a way that its results are useless (e.g. stopping a timer before the work you're benchmarking has actually been done in a browser that does it lazily)...
> (maybe I go away at weekends?)
If that's the usage pattern, then renting may or may not be cheaper than owning. 2-day rentals for $100 seems quite easy to do (heck, might be doable for $50 depending on what you rent; the $100 figure would likely include gas too), and if you do that every weekend that puts you at $5200 for the year. That's cheaper than the yearly cost of owning in many cases. Probably not even the majority, but many.
Of course if you only need the car once every few weekends, that affects the numbers a good bit. ;)
Putting plug-ins out of process is actually simpler than what this article is about, and is being targeted for much sooner. And yes, that would help with the problem you're seeing.
Tamarin isn't actually being used for anything in Gecko, anymore. nanojit is being used, of course.
> can threads be locked down to achieve this
No, because the shared memory model of threads means that if a thread is exploited and writes to memory that a "higher privilege" thread then reads, you lose.
The amount of code that needs changing here has actually been decreasing in a lot of cases.. You seem to assume that Firefox had a significantly smaller codebase at some point. It didn't, really, ever since the Phoenix project existed.
As for Flash, that's a separate issue from what this article is about; putting plug-ins out-of-process is not the same as splitting up browser rendering across multiple processes.
Firefox rendering is currently single-threaded. There are threads that are used for network access and some other things like that, but all the layout and painting happens on one thread.
Splitting it to happen on multiple threads is not that much less work than splitting it to happen in multiple processes, and the latter has certain stability and security benefits (e.g. _if_ there is a bug that allows a renderer process to be exploited that need not automatically mean a local user exploit). It also allows memory leaks to be controlled better. Yes, fixing the leaks is still important, but we can't fix the leaks in plug-ins (which is why those are moving into separate processes too) or third-party libraries (including the OS ones used for text measurement, say).
So this is more defense in depth than "surrender".
That's being done too. It's a shorter-term project than what this article is about.
That said, there are some issues with doing it, especially on Mac (apparently getting one processor to paint into another process's window is rocket science there).
> PPS: The article says it's 93 but I see 94 on Acid3's Wikipedia page for Firefox 3.6a1pre.
Sure; the article is about 3.5b4. 3.6a1pre has several months of development work on it that were not merged to the 3.5 branch (which was stabilizing instead).
Um... ATI Radeon 9600 cards do AGP, and go up to 2048x1536 resolution. They can most certainly drive an LCD at 1600x1200 with no trouble.
That's just off the top of my head; I happened to know that this card does what you want because it's sitting here in an AGP 4x slot driving a 1600x1200 LCD, and has been for two years now. Depending on pro vs non-pro versions, etc the price varies somewhere in the $60-200 range, I think.