|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
Регистрация: Nov 2003
Сообщений: 289
|
Как побороть погрешность при задании размерных свойств MovieClip (_width, _height)?
Вопрос, скорее к профи: movieclip залит битмапом(bitmapData) при помощи beginBitmapFill(). При последующем изменении размеров(._width, ._height) этого мувиклипа, в случае задания некоторых значений, реальные свойства клипа устанавливаются не точно. Пример: задаем клипу ширину 1475 (исходная 2000), а на деле клип преобретает _width = 1474.95 (такое значение видно в дебагере и при трейсе). Вопрос - как побороть? Как сделать чтобы ставишь 1475 и было 1475?
ps. все это нужно для того, чтобы сделать _плавное_ изменение размеров мувика... (остальные моменты вроде применения beginBitmapFill() вместо attachBitmap(), нужные smooting'и вроде учтены.. а иногда все равно еле заметно подергивается) |
|
|||||
Регистрация: Nov 2003
Сообщений: 289
|
Пример во вложении. Как-то слегка подергивается оно местами... В трейсе виден нюанс с размерами.
|
|
|||||
Modus ponens
|
Вся незадача в том... что если изменять размеры таким способом, то в действительности все преобразования с клипом рассчитываются по принципу:
взять из матрицы преобразования коеффициент и умножить на исходное значение, естесственно, что при больших или "неудачных" размерах желаемого результата ингода не возможно добится (точности до 8-го знака не всегда хватит). Победить, я думаю, не удасться... Если бы не нужна была картинка, можно было бы каждый кадр програмно рисовать... (так, например реализована Iris transition), а так - не, не думаю...
__________________
Hell is the possibility of sanity |
|
|||||
Регистрация: Aug 2006
Адрес: Москва \ СПб
Сообщений: 10
|
Посмотрел-повертел пример, попробовал на очень замедленном варианте просмотреть...
Проблема не в погрешности преобразования, думаю, а в общей для всех растровых анимаций (в отличие от "пленочных" кинотехнологий, напр.) проблеме масштабирования растрового изображения. В ТВ это называется "биение" - при масштабировании объекта "играют" пиксели, в особенности - на наклонных линиях с углом наклона, близким к 90 или 0 град. Общее же решение проблемы (хотя и не идеальное) - антиальясинг. Реализовать настоящий антиалиас (да еще и не просто Nearest Neighborhood, а, к примеру, Bicubic) средствами флэш нереально - BitmapData бесславно погибнет по производительности на второй тысяче пикселов при попиксельной обработке. Я бы попробовал на время зума фильтр Blur на минимуме включать. Если он только тоже провернет это дело. А скорее - отказался бы от плавного зумирования картинки, ведь судя по примеру, все равно фиксируются только крайние состояния, а между ними зум - только в качестве transition. Ну я бы другой транзишн и сделал - от масштабируемой рамочки а-ля фотошоп до "трехступенчатого" зума - т.е. трех фиксированных "степеней увеличения" с небольшой задержкой, - если ТЗ позволяет. |
|
|||||
Регистрация: Feb 2006
Адрес: Moscow
Сообщений: 552
|
Сталкивался с этим неоднократно. Особенно в проектах, где требуется доскональная попиксельная точность. Лечил так:
присваивал значение (целое числовое), потом приравнивал этоже значение, но через округление. Я это отношу к глюку Flash. Ибо даже располагая объект в точных координатах на сцене (через Properties), после нажатия на Enter иногда получаем тоже самое число с 4-мя (а то и более) знаков после запятой. И это не только с координатами так.
__________________
Учимся правильно задавать вопросы |
|
|||||
Регистрация: May 2003
Адрес: Tallinn
Сообщений: 3,181
|
но обычно повторное изменение на нормальные координаты и нажатие ентер помогает (хотя не всегда)
|
|
|||||
Регистрация: Feb 2006
Адрес: Moscow
Сообщений: 552
|
Цитата:
__________________
Учимся правильно задавать вопросы |
|
|||||
Негуру
администратор
Регистрация: Jan 2000
Адрес: Кёнигсберг in Moscow
Сообщений: 21,879
Записей в блоге: 7
|
Понятно.
Я советую посмотреть в этот момент на значение _xscale для _width или _yscale для _height. Когда я тестировал, у меня они имели цельные значения. Учитывая, что данные свойства являются геттерами/сеттерами, мы не знаем, что именно происходит в момент присваивания ширины/высоты. Возможно, при больших размерах, происходит округление процентных размеров, а не пиксельных. Отсюда и глюк. |
|
|||||
Регистрация: Aug 2006
Адрес: Москва \ СПб
Сообщений: 10
|
Цитата:
глюк в данном примере никакого отношения к погрешности Флэша не имеет. При уменьшении окна он становится _заметнее_, при растяжке на фуллскрин - практически пропадает. Т.е. ошибка в выводе на устройство, обычная для антиалиаса. При флэшевых проблемах должно было бы быть наоборот. PS. Попробуйте, коллеги, плавно и медленно отзуммировать серую линию в 1 px на черном фоне _любым_ способом (хоть прямым выводом в видеопамять ) без антиальясинга - увидите, о чем я... Последний раз редактировалось iNils; 08.01.2008 в 23:03. |
Часовой пояс GMT +4, время: 12:35. |
|
« Предыдущая тема | Следующая тема » |
|
|