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.
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 <email@example.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
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.
Author: Chris Wilson <firstname.lastname@example.org>
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
Using the particular synthetic benchmark in question on a g45:
9542.910448 Ops/s; put composition (!); 15x15
5623.271889 Ops/s; put composition (!); 75x75
1685.520362 Ops/s; put composition (!); 250x250
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.