scrolling jank in gmail http://crbug.com/25741
Linus On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth <[email protected]> wrote: > > On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin <[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
