Ha. http://tech.slashdot.org/story/09/11/03/1334203/X11-Chrome-Reportedly-Outperforms-Windows-and-Mac-Versions
On Fri, Oct 30, 2009 at 9:44 AM, Linus Upson <li...@google.com> wrote: > scrolling jank in gmail > http://crbug.com/25741 > > Linus > > > On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth <aba...@chromium.org> wrote: > >> >> On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin <e...@chromium.org> wrote: >> > General comments: Linux tends to be "lighter" which means it does >> > better on older hardware, so depending on what sorts of laptops you're >> > talking about that could be a major factor. Windowses later than 2000 >> > or so need surprising amounts of hardware to run well. (I don't >> > mention Mac below because there hasn't been much performance work >> > there yet.) >> >> I pulled out the laptops side-by-side to be more scientific about >> this. Here are the stats: >> >> XP: 2GB RAM, Core2 Duo, 2.00 GHz >> Ubuntu 9.10: 2GB RAM, Core 2 Duo, 2.40 GHz >> >> So, the Linux machine as 20% more CPU to work with. >> >> >> 1) Scroll performance is extremely good. Even on Gmail, I can only >> >> get the mouse to lead the scroll bar by a dozen pixels. On Slashdot, >> >> it doesn't even look like I can do that. >> > >> > On "plain" pages (one scrollbar on the right, no Flash) scrolling is >> > literally shifting the pixels down. On Linux we do this by sending a >> > command to the X server, which is a single process that even has the >> > graphics drivers built in so it talks directly to your graphics card >> > and can in theory do a hardware-accelerated copy. I would expect this >> > to be pretty fast. >> >> Looking at this more carefully, scroll performance on Slashdot is >> great in both Windows and Linux. On Gmail (no chat mole), there's a >> noticeable difference. Here's a visualization of the numb on the >> scroll bar: >> >> || >> || >> || >> || >> || >> || >> -- <-- Click here and pull down >> -- >> -- <-- Linux: mouse latency gets to here >> || >> || <-- Windows: mouse latency gets to here >> || >> || >> || >> || >> >> Admittedly, it's hard to see precisely, but it affects the "feel." >> Scroll on Windows feels slightly heavier. >> >> >> 2) Tab creation is very fast. Maybe the zygote is helping here? Can >> >> we pre-render the NTP on other platforms? >> > >> > The zygote is paused right at process start, before we've even started >> > a renderer. On the other hand Windows process creation is more >> > expensive. >> > >> > There is a "new tab" graph that attempts to measure this. The various >> > lines on the graph are tracking how quickly we get to each stage in >> > constructing the page. We hit the first line 20ms faster on Linux >> > than Windows likely due to the zygote and "slow" Windows process >> > creation, but process startup seems to be a relatively small part of >> > the total time. Linux hits other lines later and Linux and Windows >> > hit the finish line at around the same time. >> >> So, I retried this with a fresh profile on both. The differences are >> not as dramatic as I remember. I can't actually see a difference when >> I run them side-by-side. >> >> >> 3) Startup time is faster than calculator. >> > >> > I'm not sure if you're kidding. Do you mean Windows calculator? >> >> I meant Linux calculator. >> >> > In the limit, I'd expect us to pay a lot more on Linux due to using >> > more libraries, GTK initialization, round trips to the X server, etc. >> > but I don't know much about Windows here. >> >> I tried turning on the GTK theme. That killed startup performance. >> >> Side-by-side startup easily noticeably faster in Linux. To be more >> precise, drawing the first pixel is noticeably faster. Total startup >> time is harder to say. >> >> Interestingly startup drawing is different between Windows and Linux. >> We might want to film with a high-speed camera to see exactly what's >> going on, but here are my impressions: >> >> Linux draw order: >> 1) Fill entire window with blue (This looks bad, can we use a >> different color? White?). >> 2) Paint main UI widgets, including NTP. >> 3) Paint NTP thumbnails. >> I bet that (2) is actually broken in to two pieces, I just can't see it. >> >> Window draw order: >> 1) Paint NC region (the blue border around the edge). >> 2) Paint main UI widgets (without omnibox). >> 3) Blit NTP content area (the sweep from top to bottom is noticeable). >> 4) Paint omnibox. >> 5) Paint NTP thumbnails. >> >> Keep in mind that this all happens very fast, so I could be imagining >> things. >> >> Ideas for improving perceived windows startup time: >> >> 1) Draw a fake omnibox with the rest of the main UI widgets. >> Currently we draw the omnibox really late and it looks slow and bad. >> You can see this if you have a dark desktop wallpaper and you focus on >> where the omnibox will be. You'll see a dark rectangle inside the >> main toolbar which is the desktop showing through. We should never >> show a dark rectangle there. >> >> 2) Fill the main content area with white when drawing the main UI >> widgets. You can see this if you focus on the bottom of where the >> bookmark bar is going to be (especially when the bookmark bar is set >> to show only on the NTP). You'll see an edge there when the bookmark >> bar is draw by while the main content area is still transparent. >> There's no reason we should ever paint an edge there. >> >> I bet the reason Windows startup feels slower is whatever drawing >> operation we're using for the main content area is slow. The >> top-to-bottom sweep probably makes me feel like the browser isn't >> loaded until the sweep reaches the bottom, whereas I feel like Linux >> is done earlier in its startup sequence. >> >> Adam >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
