Hide Forgot
Created attachment 416143 [details] Sample presentation Description of problem: Impress is really slow when working with the attached (redacted) slide deck. I did not get a chance to dig in too much, but everything from opening the presentation to navigating the slides themselves takes an inordinate amount of time under RHEL6 as well as F13. RHEL5.5 users seem to indicate acceptable performance. Version-Release number of selected component (if applicable): 3.2.0-12.4.el6 How reproducible: Always Steps to Reproduce: 1. Open the presentation and attempt to navigate around. 2. 3. Actual results: Expected results: Additional info:
Speedy for me, this is only a fairly trivial 7 slide deck. I hate any potentially subjective bugs, real nightmare to state a win position on. Is there any particular hard numbers which we can attach to this, e.g. starting on slide 1, click on slide 2, takes X seconds to redraw ?. caolanm->dtardon: Is this obviously slow for you ?
Sorry, been meaning to add some more data here and got side-tracked. I'm seeing the slowness on both of my machines (Sony VAIO laptop and Intel SDV.) Both machines have nVidia graphics cards. I have another Intel SDV (with Intel graphics) which does not exhibit the lag. Lag: 7-8 seconds for OOo to launch and finish rendering the first slide 2-3 seconds attempting to switch to the VC with OpenOffice open 2-3 seconds attempting to switch between slides Just discovered that unchecking the "Display Objects from Master" which has the effect of removing the background gradient, remedies the situation.
I've an Intel card here, hence the likely "speedy for me". And this is not full-screen presentation mode, but normal mode right ? (full-screen uses cairo while non-full uses normal traditional X). Its the nouveau driver used on the nvidia cards I assume ?
Yes, non-full and using the "nouveau" driver on both machines. However you did lead me to another interesting discovery. Full-screen works perfectly fine.
I see nothing obvious on Rawhide with radeon driver. Will try RHEL 6 after update has finished (but that machine does have ATI card too...)
No visible slowdown on RHEL 6 with radeon driver either.
Any other debugging suggestions? From the data to this point, appears this is directly related to the Xorg driver itself (as opposed to an issue in openoffice.org itself.)
Maybe fiddle with x11perf, e.g. the -copypixwin500 options and see if there's any ridiculously different numbers on nouveau vs say intel. Though note bug 596081 for where my effort came a cropper. I'll try and see if I can make a standalone demo, which has eluded me so far
Created attachment 416784 [details] standalone demo, compile with gcc XCopyArea.c -lX11
Created attachment 416787 [details] binary
caolanm->jturner: Can you run the above demo on your nouveau and report the output. What I get for my nouveau is approx 650 milliseconds to 1 second 349 milliseconds. For my intel I get approx 0 to 5 milliseconds :-) If you get a big number here, which I expect, then that's our problem I believe.
OK, I will bite a bit. Jay, could you please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * output of the dmesg command, * system log (/var/log/messages), and * X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above? Thanks in advance.
Weird. On both of my nouveau-based systems, I'm getting anywhere from 0 to 5 milliseconds. Attempting to poke through some other stuff now.
Created attachment 417217 [details] dmesg output from Sony Vaio
Created attachment 417220 [details] /var/log/messages from Sony Vaio
Created attachment 417221 [details] /var/log/Xorg.0.log
I took a bit of a look into this today. OpenOffice appears to be doing some rendering operation that isn't accelerated by EXA (ie. it's not a driver-caused fallback), and this is *extremely* expensive on G80+ as we have to do a massive amount of math *per-pixel* to deal with pixmap tiling. The only immediate solution I have is that for RHEL6 we switch to using the GPU to handle tiling/detiling of pixmaps as we need to do transfers for software rendering, rather than allowing the CPU to access the tiled pixmaps. I've tested that solution, and it fixes the slowness in the presentation in question. However, there's some slight performance regressions in the general case as a result. Though, nothing too extreme.
A scratch build with the above-mentioned solution here: https://brewweb.devel.redhat.com/taskinfo?taskID=2486433
Indeed performance is significantly better with the scratch build referred to in comment 18. Will run with that code today and see if the overall performance regression is noticeable.
Any comments on how you fared with that patch in general?
All apologies. I have been meaning to update this bug and it kept slipping my mind. Almost a week later and really have not noticed any performance issues. From my perspective this is a candidate for release.
No worries, and I agree. The performance impact of the change in the general case is minimal, and prevents extreme slowness in other cases.
MODIFIED xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.el6 is in brew.
No visible slowdown on xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.el6. Jay or others could somebody confirm?
As I indicated in comment 21, I have not noticed any slow down at all.
Thank you, marking as verified (version in comment 24).