Здравствуйте!
Libreoffice Writer очень сильно тормозит на Windows 10 64. Версия LO тоже 64, 5.4.3.2. Новый ноут, 4 гб. оперативки. При этом Word 2016 не тормозит вообще, даже если несколько документов запущено. Включал и отключал OpenGL, сглаживание, ничего не помогает. На Linux раньше вообще не тормозил, но пришлось перейти на Windows. Кто-нибудь знает, как решить? Очень нужен LO. Файл прилагаю.
Тормозит при вводе текста и прокрутке. Винда свежая.
Win 7, LO 6.0 beta 2 32 bit, OpenGL отключен, видяшка Интел, все летает
Win 10 32-bit, LO 5.3.6 - тормозов на файле-примере не заметил
А у вас шрифт Arial Unicode MS стоит?
Цитата: mikekaganski от 18 декабря 2017, 20:01
А у вас шрифт Arial Unicode MS стоит?
его нет в самой виндовс ис каропке?
Нет, это шрифт MS Office
Цитата: mikekaganski от 18 декабря 2017, 20:01
А у вас шрифт Arial Unicode MS стоит?
Нет, не стоит
Тогда мне, например, трудно проверить: у меня он есть. Возможно, проблема именно в этом.
Цитата: mikekaganski от 19 декабря 2017, 12:04
Тогда мне, например, трудно проверить: у меня он есть. Возможно, проблема именно в этом.
удали его и попробуй=)
Откуда ты вообще взял, что этот шрифт на что-то влияет?
Ну, мне не хочется его удалять, чтобы что-то проверять.
Насчёт "Откуда ты вообще взял, что этот шрифт на что-то влияет?": только недавно пофиксил баг (https://bugs.documentfoundation.org/show_bug.cgi?id=113347) (ты о нём слышал), в котором проблема была связана со шрифтами (проверялся шрифт, из-за бага не принимался, и это вызывало дикие тормоза). Здесь не тот случай, конечно, но если шрифта нет, то может включаться тот код, который работал и там при ложном отказе.
Да и вообще: не "я взял, что проблема в этом", а "я предположил, что она может быть в этом".
Кстати: я ж могу там в исходник залезть и имя шрифта заменить на что угодно и посмотреть...
Мне кажется что 64-битный LibreOffice нужно вообще прекратить разрабатывать. Мои айтишники по десять раз его поменяли на куче машин и пришли к тому же выводу, к которому я пришел 3 года назад.
32-битный LO работает везде и на всех ОС, не глючит, не требует особых ODBC-драйверов, особого Python и тп.
levne - "поставьте" LibreOffice portable 32-битный и будете работать без проблем в нем годами. Ссылка (сейчас это 5.4.3, обновляется тупо "поверх", ничего не пропадает и не портится):
https://portableapps.com/apps/office/libreoffice_portable
Полнейшая глупость.
Цитата: economist от 19 декабря 2017, 12:39
Мне кажется что 64-битный LibreOffice нужно вообще прекратить разрабатывать. Мои айтишники по десять раз его поменяли на куче машин и пришли к тому же выводу, к которому я пришел 3 года назад.
32-битный LO работает везде и на всех ОС, не глючит, не требует особых ODBC-драйверов, особого Python и тп.
levne - "поставьте" LibreOffice portable 32-битный и будете работать без проблем в нем годами. Ссылка (сейчас это 5.4.3, обновляется тупо "поверх", ничего не пропадает и не портится):
https://portableapps.com/apps/office/libreoffice_portable
Сидел на 32 бит, тормоза были такие же. В одной теме вычитал, что дело в разрядности. Не помогло.
64-битный ЛО намного стабильнее работает с огромными таблицами Calc, поскольку не имеет ограничений на использование памяти, как 32 битная сборка
Нет, всё равно не могу воспроизвести, даже заменив "Arial Unicode MS" на "Surreal Manycode RU" :)
Попробуйте на всякий случай обновиться до 5.4.4.2 (http://dev-builds.libreoffice.org/pre-releases/win/x86_64/LibreOffice_5.4.4.2_Win_x64.msi) - это последний релиз-кандидат, который должен стать релизом на днях. В этом релизе поправлено кое-что насчёт производительности...
Цитата: mikekaganski от 19 декабря 2017, 10:41Полнейшая глупость.
Прекращать разработку 64-битной версии - да, глупость, согласен.
А принципиально не попробовать 32-х битную portable, которая стабильно работает на целом зоопарке XP/Vista/7/8/10 32/64bit, в "продакшене" с 12 млрд. руб. выручки в год, с макросами, большими документами и таблицами - тоже, наверное, глупость. 250 машин с 32-битным LO и OO - работают. Пробуем все версии (обычные, не pre-release, конечно), начиная с 4.3, изредка пропуская что-то что не понравилось сразу. Этот год - вообще ни одной версии не пропустили. ЧЯДНТ?
Цитата: levne от 19 декабря 2017, 10:44Сидел на 32 бит, тормоза были такие же. В одной теме вычитал, что дело в разрядности. Не помогло.
Лукавите. На 64-битах - у вас тормоза такие, что работать невозможно, а на 32-битах - "посидели", т.е. работали, и работать, значит, было все-таки можно.
Дело не в разрядности. 64-разрядный офис даст преимущества перед 32-шным только в редчайших случаях - в приложении Calc (а не во Writer) и только если там таблицы по 100000 строк, 200 столбцов и 200000 формул. Во Writer таких документов просто не бывает. Более того, 64-разрядные приложения больше по размеру (на диске и в памяти), требуют 64-разрядную архитектуру во всем (Ось, ODBC-драйверы, драйверы устройств, плагины, коннекторы итд), они появились позднее, они более глючные и их пока меньше, чем 32-х разрядных (таких же).
Офисные приложения пока не стали "показательным случаем" и мотивом перехода на 64.
Но есть приложения (графика, работа со звуком итд), которые ими стали, потому что работают с огромными файлами или требуют распаковки/рендеринга файлов в RAM, либо работают RealTime с низкой латентностью системы (DPC) и им нужно много RAM "про запас" или для предзагрузки чего-то. На 32-х разрядах ОС - 3,6 Гб RAM - это предел, а отдельные процессы часто не могут превышать 2 Гб. Грань эта условная, т.к. есть файл подкачки итп.
Держаться за 64-бита только из-за того, что это может раз в полгода пригодиться, но всегда тормозит - я бы лично не стал. Пробуйте 32 бита...
Цитата: economist от 19 декабря 2017, 14:20Пробуйте 32 бита...
Тормозит одинаково. Работать некомфортно. Пробовать то, что уже пробовал, смысла не вижу.
Сейчас почему-то тормозить при наборе перестало, но тормозит отрисовка при прокрутке...
Теоретически, может быть проблема с MSVCR (Microsoft Visual C++ Redistributable).
Например, в системе стоит не тот MSVCR, который был установлен при сборке LO.
Некоторые расширения LO на С++ требуют для себя специальной сборки/версии MSVCR (то есть не той, которая требуется для основной программы).
Цитата: Yakov от 20 декабря 2017, 09:53
Теоретически, может быть проблема с MSVCR (Microsoft Visual C++ Redistributable).
Например, в системе стоит не тот MSVCR, который был установлен при сборке LO.
Некоторые расширения LO на С++ требуют для себя специальной сборки/версии MSVCR (то есть не той, которая требуется для основной программы).
И что с этим делать? У меня только 1 стороннее расширение, это compose special characters, оно старое, может дело в нем? Но именно из-за него я до сих пор на LO
Ну, для начала проверить, связано ли торможение с расширением: удалить (отключить) и попробовать.
На всякий случай: https://support.microsoft.com/en-us/help/306560/how-to-use-the-united-states-international-keyboard-layout-in-windows
Кстати, так и не ответили, не помогает ли изменение шрифта на присутствующий в системе...
Я установил Arial Unicode MS. Не помогло.
Цитата: levne от 20 декабря 2017, 10:22
Я установил Arial Unicode MS. Не помогло.
А какая видеокарта в компьютере? Драйверы на нее последние установлены (и вообще установлены ли)?
Цитата: mikekaganski от 20 декабря 2017, 10:20
Ну, для начала проверить, связано ли торможение с расширением: удалить (отключить) и попробовать.
На всякий случай: https://support.microsoft.com/en-us/help/306560/how-to-use-the-united-states-international-keyboard-layout-in-windows
Кстати, так и не ответили, не помогает ли изменение шрифта на присутствующий в системе...
Это не совсем те надстрочные знаки, которые мне нужны. Точнее, совсем не те.
По хорошему, потестировать бы с использованием тестовых ночных сборок и терминала cygwin. Это позволило бы увидеть, не ли какого-то диагностического сообщения, возникающего постоянно параллельно с тормозами. Если бы оно было, можно было бы копать оттуда.
Тормоза сначала при наборе, а затем при прокрутке? А что вообще с ОС, может она сама тормозит?
Некоторые "удачные" новые драйверы, например от NVidia, приводили к такому эффекту.
Погоняйте free-утилиту
http://www.resplendence.com/whysoslow
http://www.resplendence.com/download/WhySoSlowSetup.exe
ЗЫ В Офисе 4 PC на Win 10/64 + LO 5422 и 543 32х-битный - тормозов нет.
Ось не тормозит, word работает нормально
Какая версия Microsoft Visual C++ Redistributable установлена?
В системе может быть установлено несколько Microsoft Visual C++ Redistributable , и программы автоматически на основе manifest-файла выбирают нужную версию, необходимую конкретной сборке программы.
Нет там никакой привязки ни к драйверам, ни к VCRedist.
1. levne использует 5.4.3.2, который получил исправление tdf#108580 (https://bugs.documentfoundation.org/show_bug.cgi?id=108580), заключавшееся в тупом копировании *всех* библиотек VCRedist и UCRT в папку программ ЛО (App-local deployment), так что ЛО этой версии не зависит от системного VCRedist вообще (так же как и все последующие в ветке 5.4; в шестёрке это изменится).
2. levne также упомянул, что "Включал и отключал OpenGL, сглаживание, ничего не помогает" (начальный пост).
Проблему нужно отлавливать путём запуска отладочных билдов.
Дополнительно можно проверить на старых версиях, на предмет наличия проблемы там; если проблема отсутствует на какой-то из версий начиная с 5.0 - можно попробовать отбисектить проблему, чтобы найти конкретную причину.
Конечно, удручает, что результат проверки каждого совета (типа, например, "попробуйте 5.4.4.2") приходится вымаливать. Но, видимо, ТС не понимает, что обратная связь помогает помогать...
Отключил расширение. Все равно тормозит при прокрутке.
Поставил 5.4.4.2 ситуация не изменилась.
WhySoSlow выдал Your system has been analyzed. Your system appears to be running fine.
No problems were found.
Что дальше посоветуете?
Цитата: levne от 18 декабря 2017, 15:23Включал и отключал OpenGL
А OpenCL?
P.S.
ЦитироватьOpenCL не используется во Writer.
Не знал. Вопрос снят.
OpenCL не используется во Writer.
Еще и начал тормозить при выделении текста больше абзаца. :beer:
Цитата: levne от 31 декабря 2017, 12:24
Еще и начал тормозить при выделении текста больше абзаца. :beer:
Вашу радость по поводу приобретения новеньких тормозов вряд ли кто-нибудь из форумчан поддержит, а то и гляди поломают тормоза, вот будет потеха, LibreOffice без тормозов — (http://www.kolobok.us/smiles/light_skin/girl_witch.gif) — никто не догонит ;D ;D ;D
Цитата: levne от 31 декабря 2017, 12:24
Еще и начал тормозить при выделении текста больше абзаца. :beer:
у меня было когда то давно торможение интерфейса при многих операциях, начиная с вызова "горячего меню" по ПКМ. Виновен оказался каким то боком пакет локализации интерфейса (украинская локаль).
Не твой случай?
Так вроде локаль русская, с сайта качал программу
OpenGL отключен.
5.4.2 работает нормально.
OC -- FC26, офис ванильный русский
Тормозят версии 5.4.3 и 5.4.4. Тормозят настолько, что работать невозможно.
Если на странице сотня-полторы svg изображений (Tex Maths Equation) или большое растровое изображение, страница скроллируется рывками по миллиметру в секунду.
Ради эксперимента потянул за ползунок вертикального скроллбара туда-сюда раз пять-семь и пошел на обед. Пришел через 40 минут -- вордпроцессор еще отрабатывает. Это какой-то позор. Включил опцию OpenGL -- работает быстрее, почти нормально, но использовать не буду -- стремно. К тому же 5.4.2 с ним не работает.
Если без OpenGL офис ы следующих версиях перестанет шевелиться, даже не представляю, что и делать...
McAaron - а что по вашему значит "большое растровое изображение"? Может вы делаете верстку неправильно?
Вот мой опыт. Если мне нужна иллюстрация "журнального" качества на пол-страницы А4 - я использую мнемоническое правило "4" - 4 мегапикселя. Т.е. оптимальное физическое разрешение фото - 2400х1800=4,32 Мпикс. Или просто - ширина фото на А4 - не более 2400 точек. Оно даст мне 300 dpi на печати на офсете (линиатура 160-260 линий) или на 6-ти цветном фотопринтере (реальное фоторазрешение около 150-200 dpi). И ставь хоть 100 мегапиксельный снимок - выше качества это не даст.
Всё что имеет больше число точек и мегапикселей (а это сейчас все зеркалки, все мыльницы, все телефоны - короче ВСЁ вокруг) - требует ручного ресайза к 2400х1800 (4:3).
Зачем вообще вставлять фото на весь А4 (книжной ориентации), имеющее размер по ширине больше 2400 точек?
2400 тчк / 8 дюймов = 300 dpi (необходимое и достаточное разрешение для фотокачественной печати, в которой "зерно" печати - неотличимо на глаз).
А в мм это как раз и есть 8 * 25 = 200 мм (ширина листа А4 без полей по 5мм).
Если же результирующее фото на А4 будет шириной, скажем, всего в 10 см (таких иллюстраций по статистике крупных издательств - больше всего), то и фото должно быть таким:
100/25*300=1200 (... х 900 = ~1 мегапиксель). Всего 1 мегапиксель!
Пользуясь этим правилом - верстал книжки во Writer с 150-200 иллюстрациями, ничего не тормозило и работало на субъективном уровне скорости "как в Adobe PageMaker". Если же бездумно вставлять непережатые фото с 12-20 Мпикс зеркалки, а потом их еще и масштабировать "в минус" встренными средствами Writer - то не только он, а любой другой редактор очень быстро начнет тупить при скролле.
Цитата: economist от 6 января 2018, 19:33
McAaron - а что по вашему значит "большое растровое изображение"? Может вы делаете верстку неправильно?
Большое -- это сканированная картинка размером 16x12 см или растровое изображение, например, иногда векторный рисунок в svg. Поскольку результат рисовальщика кроме самого офиса никто не понимает, приходится его из вектора в растр, понятный всем, перегонять. Сохранять как png c разрешением принтера (600 pdi). Это, чтобы при выводе в pdf или ps ничего не масштабировалось -- офис это делает крайне неаккуратно.
Но дело не только в этом. Поскольку вордпроцессорный рендеринг формул настолько убог, что аж тошнит, приходится пользоваться TexMaths Equation. В результате на странице может оказаться полторы сотни маленьких картинок в svg или png, привязанных как символы. Вот тут 5.4.3 и 5.4.4 просаживаются конкретно. Я так понимаю, что в процессе перехода на OpenGL что-то сломали.
Зачем использовать 3D библиотеку для рендеринга 2D-страниц мне совершенно непонятно. Единственное, что можно предположить, это нужно для анимационных эффектов импреса. Чтобы юзер мог скрывать убогость содержания за свистоперделками формы.
Цитата: McAaron от 8 января 2018, 08:48Поскольку вордпроцессорный рендеринг формул настолько убог, что аж тошнит
о чем идет речь в данном случае? Word или Writer? Формулы Math/MathML или картинки?
Цитата: McAaron от 8 января 2018, 08:48...сканированная картинка размером 16x12 см или растровое изображение... Сохранять как png c разрешением принтера (600 pdi). Это, чтобы при выводе в pdf или ps ничего не масштабировалось
16 см / 25 мм = 6,4 * 600 = 3840 - уже в 2 раза больше, чем нужно для честных 300 dpi (2400 тчк на 20 см).
Кстати, рендер ODT в PDF - OpenOffice|LibreOffice Writer делает абсолютно безупречно, но масштабировать графику внутри OpenOffice|LibreOffice Writer (да и любой другой верстальной программы - PageMaker, InDesign, QuarkXPress итд) - действительно, нужно как можно реже, особенно если это сложная верстка.
Не поддавайтесь на вбросы. Честный (или пьяный) редактор крупного издания - легко расскажет вам что "технические требования" к фото, графике, параметрам JPG-графики в PDF, откуда растут ноги 600 dpi и выше - это заговор издателей и рекламистов, с целью загрузить работой всё более ненужных в жизни фотографов и оборудование, а черезчур умных клиентов - осадить и раскрутить на более "высокую" денежку.
Выбранное разрешение печати (300, 600, 1200, 2400 итд, в dpi) в диалогах печати струйных и лазерных принтеров (а значит и офсетных пленок), что закрывает 99% печатной продукции - влияет только на фото и графику, тексты печатаются как вектор во всех технологиях печати (PCL, PS, GDI). Так что не удваивайте нагрузку на Writer. Описанные у вас "симптомы" делают работу невозможной, я с таким не сталкивался. Попробуйте делать правильно.
SVG, кстати, можно предельно корректно сконвертить свободным ImageMagick, в Сети примеров полно.
Цитата: kompilainenn от 8 января 2018, 11:46
Цитата: McAaron от 8 января 2018, 08:48... рендеринг формул ...
о чем идет речь в данном случае? Word или Writer? Формулы Math/MathML или картинки?
Writer при вставке формул через <Вставка: Объект: Формула>
Пример прилагается
Исходник весит почти 6М и загрузка не проходит, так что pdf
...
Шрифты завесили 6М
Я не уловил, где проблема в рендеринге формул. Зато вижу , что для Tex формул используется иной шрифт. Выложите исходник (я так понимаю со встроенными шрифтами) на какой-нить я.диск. ( у меня возникло предположение про тормоза...)
Цитата: economist от 8 января 2018, 13:19
16 см / 25 мм = 6,4 * 600 = 3840 - уже в 2 раза больше, чем нужно для честных 300 dpi (2400 тчк на 20 см).
Кстати, рендер ODT в PDF - OpenOffice|LibreOffice Writer делает абсолютно безупречно, но масштабировать графику внутри OpenOffice|LibreOffice Writer (да и любой другой верстальной программы - PageMaker, InDesign, QuarkXPress итд) - действительно, нужно как можно реже, особенно если это сложная верстка.
Не поддавайтесь на вбросы. Честный (или пьяный) редактор крупного издания - легко расскажет вам что "технические требования" к фото, графике, параметрам JPG-графики в PDF, откуда растут ноги 600 dpi и выше - это заговор издателей и рекламистов, с целью загрузить работой всё более ненужных в жизни фотографов и оборудование, а черезчур умных клиентов - осадить и раскрутить на более "высокую" денежку.
Выбранное разрешение печати (300, 600, 1200, 2400 итд, в dpi) в диалогах печати струйных и лазерных принтеров (а значит и офсетных пленок), что закрывает 99% печатной продукции - влияет только на фото и графику, тексты печатаются как вектор во всех технологиях печати (PCL, PS, GDI). Так что не удваивайте нагрузку на Writer. Описанные у вас "симптомы" делают работу невозможной, я с таким не сталкивался. Попробуйте делать правильно.
SVG, кстати, можно предельно корректно сконвертить свободным ImageMagick, в Сети примеров полно.
Текст разного рода отчетов и других документов набираю в Writer.
Формулы, включая одиночные математические символы в тексте, набираю там же, используя TexMaths Equation.
Иллюстрации делаю либо в Draw, либо рисую на бумаге капилярками 0.4 и сканирую 300 dpi, когда это на порядок быстрее, чем рисовать в Draw. Все, что сделано в Draw, экспортирую в png 600 dpi. Если разрешение будет ниже, при вставке в документ и на печати появляются артефакты -- следствие того, что при экспорте почему-то не записывется метрика, хотя формат png это позволяет. В png экспортирую потому что рисунок может пригодиться не только в том документе, для которого он готовился, а просмотрщики картинок не умеют odg. Кстати, Draw не умеет экспортировать svg, хотя и имеет пункт в меню экспорта.
Могу подготовить файл, котороый будет нормально скроллироваться в 5.4.2 и висеть в 5.4.3/5.4.4, если интересно.
Цитата: kompilainenn от 8 января 2018, 17:18
Я не уловил, где проблема в рендеринге формул. Зато вижу , что для Tex формул используется иной шрифт. Выложите исходник (я так понимаю со встроенными шрифтами) на какой-нить я.диск. ( у меня возникло предположение про тормоза...)
Исходник -- test2.odt.
TexMaths Eq для рендеринга формул использует texlive, а результат рендеринга (это либо растр png либо вектор svg) вставляет как символ. Шрифты он использует из texlive (pfb). В приведенном примере латех рендерится в svg.
McAaron, если хотите чтобы метрика воспринималась - тогда попробуйте TIFF и... BMP.
Для себя проблему с артефактами решил через буфер обмена, копированием/вырезкой из промежуточного приложения типа XnView.
Цитата: economist от 8 января 2018, 19:05
McAaron, если хотите чтобы метрика воспринималась - тогда попробуйте TIFF и... BMP.
Бесполезно.
TIFF
При экспорте в tiff Draw ничего не спрашивает и записывает в TIFFTAG_[XY]RESOLUTION непонятно что. Например,
Image Width: 575 Image Length: 319
Resolution: 0.166667, 0.333333 pixels/inch
Т.е. размер растра получается десятки метров?! Ну и аспект возник откуда-то.
При растяжении рисунка по вертикали в 3/2 раза TIFFTAG_YRESOLUTION устанавливается в 0.2 pixels/inch, т.е что-то там таки происходит, но что -- непонятно.
BMP
При экспорте в bmp по умолчанию разрешение устанавливается в разрешение экрана. Соответсвенно устанавливаются те Rows и Cols, что на экране. То же самое имеет место и в случае png, размер выходного файла только будет меньше из-за более продвинутого сжатия, а растр остается тем же -- бит в бит одно и тоже.
При импорте растра, экспортированного из Draw, Writer игнорирует разрешение и масштабирует изображение, втискивая его в область текста страницы, сохраняя пропорции. В результате масштабирования графика портится.
Во вложении pdf и исходник с вариантами экспорта из Draw в разных форматах с разным разрешением одного и того же рисунка при одном и том же выделении. Более менее нормальная картинка без мазни получается только при 600 dpi. Особенно это заметно на печати. Собственно, во вложении сканы двух страниц распечатанного export-test.odt на обычном лазернике.
Вот такие дела...
Обновил компьютер, поставил 8 гигов оперативки и SSD. Все равно тормоза при прокрутке. Отрисовывается текст с задержками, как бы "прыгает". Версия LO последняя с сайта.
Всем добрый день! Подниму тему: тормозит Writer при скроллинге страницы (как, в принципе, и другие приложения из пакета) на MacOS 10.14 (MBP 15 2013 года на встроенной графике). При этом в версии для MacOS не нашел настроек кэша. Подскажите, может быть есть способ ускорить работу? Спасибо!
Какие настройки:
Сервис-Параметры-LibreOffice-OpenCL ?
Сервис-Параметры-LibreOffice-Вид- Графический вывод - (Использовать аппаратное ускорение, Использовать сглаживание, OpenGL)?
Цитата: kompilainenn от 17 февраля 2019, 22:55
Цитата: vldsil от 17 февраля 2019, 22:05тормозит Writer
версия LibreOffice?
6.2.0.3
Цитата: Yakov от 18 февраля 2019, 08:43
Какие настройки:
Сервис-Параметры-LibreOffice-OpenCL ?
Сервис-Параметры-LibreOffice-Вид- Графический вывод - (Использовать аппаратное ускорение, Использовать сглаживание, OpenGL)?
Все, кроме сглаживания, было отключено. Добавил OpenGL и OpenCL - стало значительно лучше, спасибо! А опция "аппаратное ускорение" в принципе недоступна.
Цитата: vldsil от 18 февраля 2019, 20:36
Цитата: kompilainenn от 17 февраля 2019, 22:55
Цитата: vldsil от 17 февраля 2019, 22:05тормозит Writer
версия LibreOffice?
6.2.0.3
Цитата: Yakov от 18 февраля 2019, 08:43
Какие настройки:
Сервис-Параметры-LibreOffice-OpenCL ?
Сервис-Параметры-LibreOffice-Вид- Графический вывод - (Использовать аппаратное ускорение, Использовать сглаживание, OpenGL)?
Все, кроме сглаживания, было отключено. Добавил OpenGL и OpenCL - стало значительно лучше, спасибо! А опция "аппаратное ускорение" в принципе недоступна.
Вам повезло. У меня ни на одном из компов со встроенными видеоадаптерами при включенном чеке "OpenGL" офис вообще не стартует. Если же чек сбросить, офис стартует и даже шевелится. Но только до тех пор, пока не попадется какая-нибудь "фенечка", типа синенького пунктирчика разрыва страницы или я случайно не щелкну над тем местом, из которого выскакивает синяя блямба колонтитула. Сразу любое скроллирование вызывает полный ступор из-за многократной перерисовки всего окна. Видишь тормоза, снимаешь палец с мышки и вроде все это движение по миллиметру с миганием должно прекратиться, но оно ездит еще несколько минут туда-сюда. Пока содержимое проскроллируется таким образом на 10 см, можно сходить на горшок.
Такая же ситуация с ноутбуком, у которого встроенный видеоадаптер работает на свою матрицу, а дискретный (nvidia) на порты hdmi и displayport.
ИМХО, использование OpenGL в таких приложениях, как вордпроцессор никак не оправдано.
Всем привет!
Была проблема - в текстовом редакторе (Writer), после набора нескольких символов, постоянное обновление (отображение изменений) страницы - прекращалось, одноко, например, вращением колёска мышки страницу можно было обновлять, но только во время вращения такового, тут вращение можно заменить на нажатие стрелок - "вверх" и "вниз" (на клавиатуре). Ещё такое вращение колёсика помогает если какое-то меню, например "Файл", окрасилось в один цвет, вращать нужно в выпадающем меню. А если во время сохранения вылетает окно без кнопок, то для отмены сохранения нужно нажать стрелку вправо и энтер, а для сохранения просто энтер (например)
(вроде) Помогло следующее: (Открыто основное меню программы) "Сервис-Параметры-Вид-Графический_вывод-Весь_вывод_через_Skia" (Убрать галочку с "Весь вывод через Skia")
Хоть теперь и не видно, например, выделения текста, но зато видны изменения, при внесении таковых. Стали видны кнопки на окне сохранения. Выпадающие меню теперь не становятся белыми (и не появляются белыми)
Проблема решена отчасти, а может и вовсе не решена, так как подробно не проверял, но и представленная информация может кому-то пригодиться
Технические характеристики:
LibreOffice Community \ 7.2.7.2 (x86)
Win 8.1 32-bit
Samsung np-nc110-p05ru