Jump to content

Очень медленно работает предварительный просмотр


Recommended Posts

Добрый день!

Наша организация закупила NanoCad для замены AutoCad, многие функции действительно полезные, но!

Предварительный просмотр очень тормозит при зумировании и панаромировании, смена принтера большого результата не даёт. У нас достаточно большие чертежи с множеством узлов и элементов, предварительный просмотр крайне важен, дабы не тратить время на печать того же PDF (чтобы посмотреть что в нём не так отображается). Может существует какое-то внутреннее кэширование объектов, видовых экранов? Просьба к разработчикам обратить на это внимание и учесть при выпуске новых версий. Если кто-то знает пути решения проблемы - просьба откликнуться. Проблема проверена на нескольких компьютерах.

Link to comment
Share on other sites

Честно говоря, давно не использую предпросмотр. Проще напечатать в PDF и спокойно рассматривать, что где и как выглядит, заодно можно доработать чертёж рядом, не закрывая готовый лист. Так и быстрее, и удобнее.

  • Thanks 1
Link to comment
Share on other sites

Ритуалы с печатями понятны, но встроенные функции должны работать нормально. Предварительный просмотр как раз и создан для того, чтобы не тратить время на печать для предпросмотра. И уж тем более не должен обрабатывать изображение при перемещении и зуммировании, кэширование должно произойти один раз при нажатии на кнопку предпросмотр. Конечно, бывают файлы с большими подосновами, но тормозит даже на незагруженных чертежах.

  • Like 1
Link to comment
Share on other sites

5 часов назад, Almaltoron сказал:

но встроенные функции должны работать нормально

Я не спорю.

Link to comment
Share on other sites

Интересно, средний размер dwg, сколько в среднем в одном dwg: листов, включенных видовых экранов листов, подрезок видовых экранов, средние размеры и кол-во растров, наличие подрезок и их кол-во в растрах?

Если > 10 листов или >5 подрезанных видовых экранов на одном листе, то это болезнь проектировщиков

Link to comment
Share on other sites

@lidia.antipina.ru Ох сейчас с вилами и факелами толпа соберётся :D

Не касаясь остального, как влияет количество листов? У меня их в одном файле может быть и 20, и 40, в теории может быть и больше, но пока заказчик и исполнитель миловали. Предпросмотр же делается на один лист, их количество не должно ущемлять скорость подготовки конкретного листа.

Касаемо остального: речь идёт о том, что предпросмотр формируется не один раз, а перерисовывается при каждом движении, что есть неправильно. Должно один раз формировать картинку (или тот же PDF для просмотра внутри NC, если своим движком это быстро делать не получается), и далее уже работать без тормозов и полной перерисовки, как сейчас это происходит.

  • Like 2
Link to comment
Share on other sites

В 19.08.2022 в 14:19, lidia.antipina.ru сказал:

Интересно, средний размер dwg, сколько в среднем в одном dwg: листов, включенных видовых экранов листов, подрезок видовых экранов, средние размеры и кол-во растров, наличие подрезок и их кол-во в растрах?

Если > 10 листов или >5 подрезанных видовых экранов на одном листе, то это болезнь проектировщиков

Т.е. вы хотите сказать, что при предпросмотре кэшируются все листы? Тормозит даже с одним листом на чертеже. На предпросмотр количество листов влиять не должно, а количество ВЭ на листе может влиять только на скорость первого кэширования до появления картинки. Вы куда-то в сторону свернули.

добавлено через 0 минут
В 19.08.2022 в 16:20, Kreator сказал:

@lidia.antipina.ru Ох сейчас с вилами и факелами толпа соберётся :D

Не касаясь остального, как влияет количество листов? У меня их в одном файле может быть и 20, и 40, в теории может быть и больше, но пока заказчик и исполнитель миловали. Предпросмотр же делается на один лист, их количество не должно ущемлять скорость подготовки конкретного листа.

Касаемо остального: речь идёт о том, что предпросмотр формируется не один раз, а перерисовывается при каждом движении, что есть неправильно. Должно один раз формировать картинку (или тот же PDF для просмотра внутри NC, если своим движком это быстро делать не получается), и далее уже работать без тормозов и полной перерисовки, как сейчас это происходит.

Всё верно! Работает предпросмотр неправильно!

Link to comment
Share on other sites

Тема с кэшированием не столь однозначна.

Например, в АС для этого есть

Спойлер

image.png.1ba1abfb3f80ea5eba39e6ce372442c5.png

 

Вот по этой теме

Спойлер

image.png.9850f33320fad53160616e10c133cade.png

 

К сожалению, в NC переменной LAYOUTREGENCTL не существует.

Поэтому, способ кэширования скрыт от пользователя. 

Тут только @Lion007 сможет разложить по полочкам, как что и когда прорисовывается.

Edited by EdwardSt
Link to comment
Share on other sites

Такс. прошу прощения - отсутствовал... но могу и разложить...

Сразу краткое резюме : не было, нет, не будет. И не надо. Нет, правда не надо... а вот почему - это уже дальше будет многабукф.
Нет, то есть если кому-то остро необходим сам сисвар - то это без проблем, но обрабатывать его никто не будет. И вот почему...

Зайдем с начала - нафига оно вообще? Вопрос риторический, с одной стороны - а с другой - на него есть конкретный ответ.
В чем, собственно, проблема? А в том, что переключение лэйаутов (мягко говоря) происходит вовсе не так быстро, как хотелось бы. А в ряде случаев - тупо люто торрмозит. Недовольство понятно и законно. 
При этом РЕГЕН чертежа - в общем случае операция не особо быстрая. Ну а кэширование - теоретически - способно ускорить то, чего кэшируют... В данном случае - предполагается, что ежели мы на лист сходили (и да, честно подождали, пока отрегенится) - то потом можем переключаться на него мушкой.
И настройка сия - именно про это. Ну так вот, нано *всегда* работает по первому варианту.
И ведь что получается : если чертеж вменяемого размера (и, кстати, вменяемо устроен) - то он регенится вменяемо быстро. Если приключаются тормоза - то, как, правило, это просто он такой себе тяжелый чертеж. В нем регенить надо *много*. а если много регенить - то и хранить придется тоже много. А память не резиновая...
Еще один момент - он будет дико бесить тех, кто просто щелкает по вкладкам... чисто позырить... нано - это редактор. там можно все подряд поменять.
а если я в модели что-то поменял - мне же и листы надо обновить, ага? ну или хотя бы тот самый кэш инвалидировать к едрене фене... и потом (а плевать на настройки - старые данные-то полюбасу не подойдут) - опять регенить лист заново...
частичная инвалидация - тоже вариант так себе, поди пойми, что на что влияет и каким образом оно одно за другое зацеплено.

Я вот тут одному юному падавану приводил пример :
Вот он сочинил объект. Который тупо рисует линию (0, 0) - (100,100). имеет право? вроде как да... А какого цвета? А он перебирает датабэйз, и если находит там, скажем точку, в координатах (0,0) - то копирует ее цвет. Тоже имеет право... это его объект, и не мне его судить!

и вот что будет с вашим кэшированием? а будет там хрень!
в первый раз (когда закэшировали) - линия будет (например, в листе) зеленая, потом ее (в модели) сделают красной... явной связки - за которую платформа может схватиться - просто нет. что делать? точка - и так инвалидируется, ее всяко регенить. как от нее прочие объекты зависят - да вообще без понятия! :)
и кэш мгновенно превращается в тыкву после *любой* модификаяции. в том числе - и зум колесиком, и проч... да и само по себе переключение тоже!

Ни одна же зарраза мне не запретит отследить номер текущего лэйаута - и назначить чему-то цвет в соответствии с ним?
а удали я один из них... опять - любая модификация превращает все в тыкву.


Что осталось? А, те, кто чисто щелкают туда-сюда... случай весьма специфический. *иногда* можно *было бы* тупо восстановить картинку. вот об этом подумаем, но это опять жор ресурсов!

а памяти и так не хвататет - если проблемы :)

Мораль сей басни проста : проблема не в отсутствии кэширования (кому нужен сисвар - например для совместимости со скриптами - обращайтесь, это не проблема) - проблема в медленном регене. да, знаю, нано регенит тормозно. мы над этим работаем, хотя пока и без сокрушительного успеха - привходящие обстоятельства есть.

Ну и на будущее... Это уже безотносительно к собственно сабжу - у нас с АС принципиально разный подход. Они оптимизируют выполнение среднепотолочных задач - честь им за это и хвала. У наны идеология другая - нано может (и регулярно делает это) люто тормозить. но при этом память (которая не резиновая) старается не жрать - и алгоритмы, как правило, конечны. грубо говоря - если ждать достаточно долго, то задача будет решена. Утешение сомнительное, но не уверен, что быстрое падение по дороге лучше :)
Правда - может и такое случиться - то конец алгоритма наступит после тепловой смерти вселенной, пересечение многоэтажных блоков у меня выдавало такие прогнозы... но вдруг у вас быстрый комп? :)
 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

В 27.08.2022 в 04:34, Lion007 сказал:

не было, нет, не будет

Я все многабукф прочитал. честно. но так и не понял, зачем при предварительном просмотре печати чертеж регенерируется после каждого зуммирования? чтобы память не жрать? но он же отрендерился полностью после установки галочки "предварительный просмотр" и уже сожрал память. очень ли нужно ее (память) оперативно освобождать после каждого зуммирования?

добавлено через 0 минут

или я вообще не алё?

Link to comment
Share on other sites

Похоже, предварительный просмотр регенерируется в любом случае.

И зуммирование тут может быть совсем даже при чем. Например, если в качестве области печати выбран экран.

 

Текст выше (вот все время читал бы и читал подобное!) был про регенерацию/нерегенерацию при переключении между вкладками.

И основной вывод вы уловили совершенно четко: не было, нет и не будет.

По-видимому, это общие вопросы производительности, связанные с пересчетом чертежа, а не с функцией предпросмотра.

  • Like 1
Link to comment
Share on other sites

2 часа назад, XPom сказал:

Я все многабукф прочитал. честно. но так и не понял, зачем при предварительном просмотре печати чертеж регенерируется после каждого зуммирования? чтобы память не жрать? но он же отрендерился полностью после установки галочки "предварительный просмотр" и уже сожрал память. очень ли нужно ее (память) оперативно освобождать после каждого зуммирования?

А он и не регенрируется каждый раз. Там регены случаются при изменении параметров печати. То многобуквие, которое я произвел - это вообще не про превью, это просто переключение лэйаутов документа (модель->лист, или между листами).

С непосредственно предпросмотром печати - ситуация другая. Поскольку это именно предпросмотр печати - то подготавливается некий "печатный образ" - в зависимости от принтера (EMF\PDF\растр и тэ дэ). подготовка этого самого образа - это да, это реген (а никуда не денешься, рисование для печати и для обычного отображения - это две разные вещи). А дальше уже этот самый образ показывается при предпросмотре. И, естественно, что отыгрывание метафайла, что рендер PDF - штука вовсе не такая быстрая, как хотелось бы...

  • Like 1
Link to comment
Share on other sites

1 час назад, Lion007 сказал:

многобуквие, которое я произвел - это вообще не про превью, это просто переключение лэйаутов

это я понял

 

1 час назад, Lion007 сказал:

А дальше уже этот самый образ показывается при предпросмотре. И, естественно, что отыгрывание метафайла, что рендер PDF

нельзя сделать так, чтобы он отрендерился при взведении галки, а потом при зумировании не перерендивался? может добавить опцию типа "ручное обновление"? иначе пользоваться им на насыщенных чертежах нереально

Link to comment
Share on other sites

50 минут назад, XPom сказал:

нельзя сделать так, чтобы он отрендерился при взведении галки, а потом при зумировании не перерендивался? может добавить опцию типа "ручное обновление"? иначе пользоваться им на насыщенных чертежах нереально

к сожалению, так не получится. образ документа - штука векторная (куча линий). чтобы  ее показать - хочешь не хочешь, а каждую линию из этой кучи придется нарисовать - с учетом зума\пана. причем если с паном еще можно поиграться (например, отрисовать не только видимую область, а весь чертеж), то с зумом ничего вразумительного поделать нельзя. максимум - можно отрисовать картинку с финальным разрешением принтера, и зумить дальше уже растр - но такое рисование - штука тоже небыстрая, да и размер растра получается чудовищный, так что работать с ним тоже ой как не быстро. это если он вообще в память влезет... это не говоря уже о том, что качество самой превьюшки в таком случае будет существенно хуже.

что касается галки... лишняя галка - лишняя путанка. вот что можно проделать - так это при включении\выключении показа превью не сбрасывать зум-пан. это да, это можно... т.е. с выключеным превью отзумиться в нужное место, а потом включить показ превью - и увидеть нужное место. тоже, конечно, корявостно...

 будем думать...

  • Like 1
Link to comment
Share on other sites

56 минут назад, Lion007 сказал:

т.е. с выключеным превью отзумиться в нужное место

в слепую,  в нужное место?

или я мысль не понял(((

Link to comment
Share on other sites

5 минут назад, doctorraz сказал:

в слепую,  в нужное место?

или я мысль не понял(((

не то, чтобы совсем прямо вслепую - там большая буквия нарисована :)
но в целом да, по запаху и приборам :)

  • Haha 3
Link to comment
Share on other sites

@Lion007 вот не уверен, что для превью, просто посмотреть нужно такое.. 

И пдф из растровых подложек 1 Мб не должен весить 100 Мб, а в акробате устраивать слайдшоу, да еще когда в итоговый файл педееф попадает скрытое клипом (подрезанное)

в оригинале это все работает достаточно шустро и педеефы при дпи 600 вместо нанодефолтных 300 получаются в разы легче..

Эт я к тому, что если б не с чем было сравнить возможно согласился с "объективными" сложностями, в оригинале этих сложностей нет, а на бумаге и в педееф все одинаково выглядит.. только нано тормозит безбожно

добавлено через 6 минут

Чессно говоря руки опускаются, когда вместо правки задокументированных , подтвержденных багов нанодев выпускает муляжи новых фич, а когда еще и  работающий функционал ломают или дауншифтят его...  

Упростить нану, чтобы бим лучше брали?

Нет у меня другого объяснения(((

Link to comment
Share on other sites

В 29.08.2022 в 21:05, doctorraz сказал:

Чессно говоря руки опускаются, когда вместо правки задокументированных , подтвержденных багов нанодев выпускает муляжи новых фич, а когда еще и  работающий функционал ломают или дауншифтят его...  

Ты под каждым сообщением будешь писать "Carthago delenda est" "Нана в обновлениях получает не только новые фичи, но и новые баги"? :D Ты ж имей в виду, они сейчас пилят очередное обновление, и каждый твои пинок ударяет по кружке с чаем у программера, он нервничает... Может случайно ударить по клавиатуре, или чай разольётся, и чего-нить ещё сломается в коде из рабочего :D Теперь мы знаем, кто во всём виноват :lol:

Извините...:offtopic:

  • Haha 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Tell a friend

    Love Официальный форум компании Нанософт? Tell a friend!
×
×
  • Create New...