Я еще заметил, если писать текст в разных элементах вывода статического текста, то при большом количестве таких элементов ОЗУ визуализации быстро выходит за 100%. Объединив текст в один элемент на весь экран получаем заметное снижение ОЗУ.
На картинке если весь текст писать отдельно - было 117%. При частичном объединении стало 83%.
конфигурация.png
Провёл эксперимент. Все мои рисунки прекрасно уместились в ПР205, память заполнена на 46%. Картинки уменьшены под экран ПР205.
Так что ПР225 ещё пока недоведена до ума... Имеет достаточно мощный функционал по периферии и управлению, но ограничена в визуализации. Солидный проект на ней будет сложнова-то сделать.
Последний раз редактировалось Vadik2881; 02.02.2026 в 11:23.
Здесь разработчики немного промахнулись - экранчик увеличился, а память под картинки осталась прежняяСообщение от Vadik2881
Так ещё не вечер, может флешку припаяют или ОЗУ, в смысле, чего не будет хватать!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Так "bmp" это не сжатый формат, конечно можно уменьшить размер файла в несколько десятков раз с потерей качества изображения, сжав его в формате "ipg", и для наших целей это больше подходит, для экрана ПР не нужна картинка высокого разрешения и студийного качества!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
Сергей0308 вы знаете что делает ОЛ при "копировании" рисунка в ПР? вполне вероятно, приводит все к bmp, чтобы ПР потом не перетруждался. То есть все приводится к пикселям, тем самым, увеличивая файл проекта.
От Овен так никто и не "выступил" с объяснениями
Ну а зачем им что-то объяснять, в смысле, дело уже сделано!
Несжатый формат требует минимум ресурсов ПР, это похоже на правду!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
поэтому png был бы предпочтительным вариантом, есть компрессия и прозрачность.
Мне кажется, обработка изображений - отнюдь не самое однозначное дело.
Пример.
Сделайте скрин png какой-нибудь программы в OwenLogic.
Обработайте его пакетом сжатия без потерь FileOptimizer
Уменьшите размер изображения в 2 раза
Снова сожмите.
И вот в этом месте будет удивление - уменьшенный в размерах файл будет по размерам больше исходного на 50%.
Произойдёт это из-за размытия цветов пикселей при кубической интерполяции при уменьшении размера. Т.е. сжать будет уже невозможно - в исходном были одинаковые соседние пиксели, а в уменьшенном - сильно разные, плохо поддающиеся сжатию.
А т.к. счастья нет, то для изображений 240х320 можно выбрать и несжатый формат.
Или обязать полуграмотного пользователя самостоятельно готовить изображения под сильное сжатие и только заданного размера и глубины цвета, что вызовет недовольство - мол у конкурентов всеядные компоненты берут всё, что дают.
Поэтому лично я просто принял такую ситуацию с изображениями, как данность.
Прикреплю пример png до и после уменьшения размера 100% и 70% от исходного и обработкой по оптимизации
Результаты:
исходный файл 100% размер - 16809 байт
уменьшенный файл 70% размер - 58593 байт
Последний раз редактировалось FPavel; Вчера в 16:09.
Прибору, действительно, не важно в каком формате будет загружено изображение в редактор визуализации. Расчет Пользовательского ПЗУ визуализации для изображений - Ширина х Высота х 2. Важно заметить, что в расчет берется исходное изображение, которое загружается в редактор визуализации, а не скорректированные размеры уже в редакторе. Это позволяет использовать копипасту одних и тех же изображений без увеличения занимаемого Пользовательского ПЗУ визуализации.
Инженер по продукту | ПР и Owen Logic
email: k.korolev@owen.ru
Ваши права
Ответить с цитированием