Created attachment 120383 [details] Screenshots My document works perfectly fine under libreoffice 4.x If i open it with libreoffice 5.0.3.2 the pictures show in low resolution. Scrolling sometimes needs 8 sec to scroll a single page, rendering only half the screen while scrolling. Every page update needs at least 5 sec. My computer should be fast enough for a text writer. (i7 3,8ghz, 16gb ram, ssd) The attachment shows a screenshot of libreoffice with the broken images. The other screenshot shows the pdf export. I can provide the document for testing, but not public.
What is your version of MS-Windows ? Please, try to disable use of OpenGL in menu Tools > Options > LibreOffice > View --> Use OpenGL for all rendering. Best regards. JBF
Windows 10.0 Pro Build 10240 For the Work arround, I went back to libreoffice 4.4 which works fine. I suppose libreoffice has problems with svg files.
The PDF issue is bug 94739. I think it is safe to assume the scrolling problem is also caused by OpenGL being used. Peter: can you give us your graphics card model? I will add this to the meta bug as no scrolling issue is yet in it.
--------------- Display Devices --------------- Card name: NVIDIA GeForce GTX 980 Manufacturer: NVIDIA Chip type: GeForce GTX 980 DAC type: Integrated RAMDAC Device Type: Full Device Device Key: Enum\PCI\VEN_10DE&DEV_13C0&SUBSYS_31701462&REV_A1 Display Memory: 12172 MB Dedicated Memory: 4009 MB Shared Memory: 8162 MB Current Mode: 1920 x 1080 (32 bit) (60Hz) Monitor Name: Generic PnP Monitor Monitor Model: SMBX2431 Monitor Id: SAM0771 Native Mode: 1920 x 1080(p) (60.000Hz) Output Type: HDMI Driver Name: nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um Driver File Version: 10.18.0013.5887 (English) Driver Version: 10.18.13.5887 DDI Version: 12 Feature Levels: 12.1,12.0,11.1,11.0,10.1,10.0,9.3,9.2,9.1 Driver Model: WDDM 2.0 Graphics Preemption: DMA Compute Preemption: DMA Miracast: Not Supported Hybrid Graphics GPU: Not Supported Power P-states: Not Supported Driver Attributes: Final Retail Driver Date/Size: 11/2/2015 18:03:07, 15839200 bytes WHQL Logo'd: n/a WHQL Date Stamp: n/a Device Identifier: {D7B71E3E-5080-11CF-2D61-7D111CC2C735} Vendor ID: 0x10DE Device ID: 0x13C0 SubSys ID: 0x31701462 Revision ID: 0x00A1
I installed LibreOffice 5 on a far older computer and it works fine there. So it seems to be a hardware or driver related problem. I first thought disabling the option you mentioned didn't work, but after trying again i noticed that it only takes effect after restarting the program. A remark about that should perhaps be added, or at least a tooltip. With opengl disabled it works fine with my regular computer as well, without performance problems. Thanks for the workarround tip.
(In reply to Peter Schneider from comment #5) > A remark about that should perhaps be added, or at least a tooltip. A remark has been added, it is in 5.1.
Technically unconfirmed, but I'm comfortable setting NEW given its association with the OpenGL rendering, and OPs reported successful workaround by disabling OpenGL rendering. @Peter Schneider -- as additional releases are made (or by testing now with daily TB builds of Master or 5.1.0 branches) at some point you may find this resolved with OpenGL rendering active. We'll leave this in your hands (as you've not provided the document for testing) so please set this issue "Resolved" "Works for Me" at the point you find it working well with OpenGL enabled. Of course, if you to do spot the specific work on OpenGL rendering that clears this, you could make a note here and close this as Fixed. Till resolved, feel free to add additional comment, even a redacted version of your document for others to test with and formally confirm. And as this is left open, others may find it and attach test documents that will need review... welcome to QA =) =-ref-= Notes on installing the TB daily builds in parallel for testing https://wiki.documentfoundation.org/Installing_in_parallel
Would it be possible for you to re-test this with a recent LibreOffice 5.1.0 build - ideally RC1 - the hope is that a recent patch to do idle swap-buffers should really help scrolling / editing interactivity. Thanks !
In Version 5.1.0.0 beta 2 there is no change the bug still persists. The proposed RC1 i cannot locate.
(In reply to Peter Schneider from comment #9) > In Version 5.1.0.0 beta 2 there is no change the bug still persists. > The proposed RC1 i cannot locate. As Michael M. requested--please test with 5.1.0.1 (aka. RC1), or better with a 5.2.0alpha1+ from the TinderBox builds, where most current work on OpenGL has been applied: http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF/ (32-bit vs2013) http://dev-builds.libreoffice.org/daily/master/Win-x86_64@62-TDF/ (64-bit vs2013) But, you would want to install those "in parallel" (msiexec.exe /a administrative install). How-to for that is here: https://wiki.documentfoundation.org/Installing_in_parallel/Windows
(In reply to Peter Schneider from comment #9) > In Version 5.1.0.0 beta 2 there is no change the bug still persists. > The proposed RC1 i cannot locate. Sorry, should have added that the RC1 pre-release sits in its own directory on the web file server. They remain here until "released" to the mirror service or are archived. http://dev-builds.libreoffice.org/pre-releases/ All prior "release" builds are archvied here if you need to check behavior on an older build. Same "parallel" install works with these as with the TB dailys.
(In reply to V Stuart Foote from comment #11) > All prior "release" builds are archvied here if you need to check behavior > on an older build. Same "parallel" install works with these as with the TB > dailys. Sorry here is the link for that: http://downloadarchive.documentfoundation.org/libreoffice/old/ Time to quit for the day...
I did test it with master~2015-12-15_13.10.55_LibreOfficeDev_5.2.0.0.alpha0_Win_x64_en-US_de_ar_ja_ru_qtz.msi The Problems with opengl rendering images persist. In addition the program crashes with bad allocation error, after scrolling about 80 pages.
@Peter S. -- what is the composition of writer .ODT holding the Images as in the sample. In writer, are the images embedded OLE from draw, or are the inserted SVG/PNG/JPEG--how is the document assembled so we can recreate similar. @Michael M., any guidance on what is needed to triage... did you want to work with his original document?
OP sent me a link to proprietary sample document in PM. On Windows 8.1 Enterprise 64-bit en-US with nVidia K2000 (354.56 driver) and Version: 5.2.0.0.alpha0+ (x64) Build ID: cfe08df695c046371c4361a434176e6381e3e064 CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-12-15_13:10:55 Locale: en-US (en_US) I did not have the scrolling issues of OP, rather LO would crash as I paged through and hit page 70. Using Navigator to go to page 70 would crash, as would paging backward from page 71. @Peter S., what elements are on page 70? Document is consistently crashing with a "bad allocation" error. See if you can extract content on that page into another document--doubt it would clear up the rendering issues on scrolling, but may have another issue with an object on that page that will need to be checked.
On page 70 are only 2 math formulas a page ref. And some common text using courier and times. Some paragraphs with format do not split. I don't really assume the crash has to do with that page. You can test yourself, i'll keep the link valid for the rest of the year. I only don't want the document in public permanently. www.lathanda.de/Inf10.odt (valid until 1.1.2016)
No problems with OGL enabled in 5.0.4. Can't test with master or 5.1 as all apps crash on OGL. If we only had master builds from Tinderbox 39, we could get a backtrace of the crash.. https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg Win 7 Pro 64-bit, Version: 5.0.4.2 (x64) Build ID: 2b9802c1994aa0b7dc6079e128979269cf95bc78 Locale: fi-FI (fi_FI)
Stuart - great that you can reproduce something like this: any chance of a stack-trace from the crash ? - particularly from a (newer) dbgutil build ? [ still fixing a number of bugs there in recent times ].
Created attachment 121722 [details] three runs WinDbg 32-bit stack traces with OpenGL (In reply to Michael Meeks from comment #18) > Stuart - great that you can reproduce something like this: any chance of a > stack-trace from the crash ? - particularly from a (newer) dbgutil build ? [ > still fixing a number of bugs there in recent times ]. On Windows 8.1 Pro 64-bit with Version: 5.2.0.0.alpha0+ Build ID: 4a8c0d313540bd78c9c381edd548b976c580ca9a CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-04_02:00:52 Locale: en-US (en_US) stack trace(s) attached... picking up symbols from Clophs server. Sorry no Windows dbg build to work against.
Hi Stuart - those are some interesting traces; but they all appear to be crashes during DeInitVCL -> ie. during shutdown (is that expected ? if so - perhaps different to this bug (?)). I guess it would be good to reproduce this with LibreOffice 5.1.0 RC2 due out later this week - since so much has changed for the better there in regard to the VCL / GL code. Thanks !
@Peter, (In reply to Peter Schneider from comment #16) > I only don't want the document in public permanently. > > www.lathanda.de/Inf10.odt (valid until 1.1.2016) Could you put up a link to your problem document again so a couple of the Devs can grab it directly to test against. It is just a little to large to reliably send in a PM to folks.
Created attachment 121916 [details] WinDbg ST kp -- before exception (In reply to Michael Meeks from comment #20) > Hi Stuart - those are some interesting traces; but they all appear to be > crashes during DeInitVCL -> ie. during shutdown (is that expected ? if so - > perhaps different to this bug (?)). > On Windows 10 Pro 64-bit with Version: 5.2.0.0.alpha0+ Build ID: c71b5b4d2ec76c0a204f9515dece1e0e0689ce3c CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-13_00:15:52 Locale: en-US (en_US) Get the same crash at page 70 of document (thankyou Peter for putting it back up at the same link). ST ~* kp attached here. And WinDbg Analyze of exception to follow.
Created attachment 121917 [details] WinDbg analysis of crash WinDbg analysis of crash.
With OpenGL disabled on Version: 5.2.0.0.alpha0+ Build ID: c71b5b4d2ec76c0a204f9515dece1e0e0689ce3c CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-13_00:15:52 Locale: en-US (en_US) The scrolling and page movement *is* much smoother with OpenGL disabled. No noticeable delays as the canvas is refreshed. A visual glitches as the page canvas gets refreshed (or catches up with the scroll)--but a much better feel than the stops that occur with OpenGL active. However, the hang/exception occurs at the same point in the document on page 70. A !analyze -v shows the same unoxmllo.dll error at line 145 of unoxml\source\dom\node.cxx =-=-= with this opengl_device log. DriverVersion: 10.18.13.5850 DriverDate: 10-2-2015 DeviceID: PCI\VEN_10DE&DEV_1380&SUBSYS_37553842&REV_A2 AdapterVendorID: 0x10de AdapterDeviceID: 0x1380 AdapterSubsysID: 0x37553842 DeviceKey: System\CurrentControlSet\Control\Video\{8BE1DBA2-2F4C-4D35-826E-7753ABC13F6A}\0000 DeviceString: NVIDIA GeForce GTX 750 T
*** Bug 97754 has been marked as a duplicate of this bug. ***
This bug with slowness and crashes or bad display is reproducible also on Linux Debian Jessie with another document. $ uname -a Linux chro 4.3.0-0.bpo.1-amd64 #1 SMP Debian 4.3.3-7~bpo8+1 (2016-01-19) x86_64 GNU/Linux
Hey Stuart - thanks for the windbg analysis ... we badly need a trace like that from a dbgutil build - or at least where the symbol server has been setup - can you reproduce that with a release build eg. 5.1.1 RC1 - which has a very similar GL stack. Ultimately Stuart's trace shows a crash in checkForUpdates - which is unusual =) c71b5b4d2ec76c0a204f9515dece1e0e0689ce3c has a particularly nasty memory corruption which we've just fixed that could cause apparnetly un-related instability by corrupting the heap cf. bug#97700 ... So could you try to reproduce the crashes with 5.1.1 RC1 (which has the above fix). Thanks !
Created attachment 122575 [details] ST from breakpoint at page 70 issue of the inf10 sample (In reply to Michael Meeks from comment #27) > Hey Stuart - thanks for the windbg analysis ... we badly need a trace like > that from a dbgutil build - or at least where the symbol server has been > setup - can you reproduce that with a release build eg. 5.1.1 RC1 - which > has a very similar GL stack. ... > So could you try to reproduce the crashes with 5.1.1 RC1 (which has the > above fix). Thanks ! Think I got it, same spot where it hit break point. Attached
Created attachment 122580 [details] stepped over BP and caught two more ST before the "bad allocation" error @Michael, * Sorry, unable to get it to dump a log for analysis. But two more stack traces after BP before the "bad allocation" error in the test inf10.odt writer document. Attached, HTH!
(In reply to V Stuart Foote from comment #29) > Created attachment 122580 [details] > stepped over BP and caught two more ST before the "bad allocation" error > > @Michael, * > > Sorry, unable to get it to dump a log for analysis. But two more stack > traces after BP before the "bad allocation" error in the test inf10.odt > writer document. Maybe this helps (quoting myself from another report): For the SAL_LOG=1, you would need a cygwin terminal. https://cygwin.com/install.html Then you launch the cygwin terminal and: cd /cygdrive/c/path-to-my-libreoffice/program and then you can execute it with: SAL_LOG=1 ./soffice.exe 2>&1 | tee sal-log.txt It will create a log file sal-log.txt in the launching folder.
Hi Stuart; thanks for the traces - I guess the latter two are un-related (or perhaps just much more helpful) than the shutdown & checkForUpdates red-herrings =) They both look like heap corruption. Is there any chance of a drmemory trace of a dbgutil build there ? hopefully that will give us exactly what we need. Thanks !
Bit of a franken-bug this one =) Tomaz fixed a number of crash on exit issues in bug#100814, bug#96920 etc. - Tomaz has also done a chunk of work to accelerate rendering for an increasing number of corner cases. Re-testing 5.1.4.2 or better a 5.2 build and opening a new & more focused bug if problems recur would be much appreciated =) Thanks for filing !