I've tested opera 9.64 ans new 10 opera snapshots. The bug is the same. Scrolling is horribly slow, so slow, I can't work with opera. It is on every intel driver, when UXA is active. When i installed legacy driver (running on EXA) scrolling in opera is pretty fast. lspci 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
Needs the usual info (Xorg.0.log, dmesg, sysprof if your performance problem is when the CPU is near 100% busy)
http://pastebin.com/m6b1b70ed - dmesg http://pastebin.com/m406d6b11 - Xorg.0.log
> --- Comment #2 from Mateusz Tracz <matiqing@gmail.com> 2009-07-14 01:34:56 PST --- > http://pastebin.com/m6b1b70ed - dmesg > http://pastebin.com/m406d6b11 - Xorg.0.log please always attach files directly on bugzilla instead of using pastebin sites where they can expire…
I'll remember for future
Anybody?
You won't do anything?
Is the CPU near 100% use during scrolling? If so, could you run sysprof and attach the results? (please remove NEEDINFO keyword when updating the bug with requested information)
No CPU is less than 15% when scrolling
I note that with KMS enabled it is little better. Of course still it is horrible.
Anybody has a similar problem?...
unblocking Q3 release, but still a high priority bug.
This sounds like Opera may very well be using PutImage when scrolling. Mateusz, does commit 19d8c0cf50e98909c533ebfce3a0dd3f72b755c1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Nov 29 21:16:49 2009 +0000 uxa: PutImage acceleration Avoid waiting on dirty buffer object by streaming the upload to a fresh, non-GPU hot buffer and blitting to the destination. This should help to redress the regression reported in bug 18075: [UXA] XPutImage performance regression https://bugs.freedesktop.org/show_bug.cgi?id=18075 Using the particular synthetic benchmark in question on a g45: Before: 9542.910448 Ops/s; put composition (!); 15x15 5623.271889 Ops/s; put composition (!); 75x75 1685.520362 Ops/s; put composition (!); 250x250 After: 40173.865300 Ops/s; put composition (!); 15x15 28670.280612 Ops/s; put composition (!); 75x75 4794.368601 Ops/s; put composition (!); 250x250 which while not stellar performance is at least an improvement. As anticipated this has little impact on the non-fallback RENDER paths, for instance the current cairo-xlib backend is unaffected by this change. improve performance for scrolling in Opera?
Mateusz, have you had time to try the patch posted in comment #12?
I don't have Opera, hence why it is difficult to determine which paths are causing the slow behaviour whilst scrolling. Even though the cpu is only at 15% utilisation, a perf profile would help identify the hot paths, and an xtrace would like us know the macro requests being issued. Together that might be enough to identity the cause and whether we can improve our driver. Thanks.
I was pointed to an opera package which I duly installed to find the reason for Opera being slow... They have implemented a client side renderer which uses *PutImage* into a backing store and then CopyArea onto their window. The aforementioned patch will help a lot, but this is always going to be slow (and slower in UXA due to relocation overhead). The driver does now support SHM Pixmaps which can be used by client side software renderers to minimise transport costs.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.