Как побороть погрешность при задании размерных свойств MovieClip (_width, _height)?
 

Вопрос, скорее к профи: movieclip залит битмапом(bitmapData) при помощи beginBitmapFill(). При последующем изменении размеров(._width, ._height) этого мувиклипа, в случае задания некоторых значений, реальные свойства клипа устанавливаются не точно. Пример: задаем клипу ширину 1475 (исходная 2000), а на деле клип преобретает _width = 1474.95 (такое значение видно в дебагере и при трейсе). Вопрос - как побороть? Как сделать чтобы ставишь 1475 и было 1475?

ps. все это нужно для того, чтобы сделать _плавное_ изменение размеров мувика... (остальные моменты вроде применения beginBitmapFill() вместо attachBitmap(), нужные smooting'и вроде учтены.. а иногда все равно еле заметно подергивается)

Пример во вложении. Как-то слегка подергивается оно местами... В трейсе виден нюанс с размерами.

Вся незадача в том... что если изменять размеры таким способом, то в действительности все преобразования с клипом рассчитываются по принципу:
взять из матрицы преобразования коеффициент и умножить на исходное значение, естесственно, что при больших или "неудачных" размерах желаемого результата ингода не возможно добится (точности до 8-го знака не всегда хватит).
Победить, я думаю, не удасться...
Если бы не нужна была картинка, можно было бы каждый кадр програмно рисовать... (так, например реализована Iris transition), а так - не, не думаю...

Посмотрел-повертел пример, попробовал на очень замедленном варианте просмотреть...
Проблема не в погрешности преобразования, думаю, а в общей для всех растровых анимаций (в отличие от "пленочных" кинотехнологий, напр.) проблеме масштабирования растрового изображения. В ТВ это называется "биение" - при масштабировании объекта "играют" пиксели, в особенности - на наклонных линиях с углом наклона, близким к 90 или 0 град.
Общее же решение проблемы (хотя и не идеальное) - антиальясинг.
Реализовать настоящий антиалиас (да еще и не просто Nearest Neighborhood, а, к примеру, Bicubic) средствами флэш нереально - BitmapData бесславно погибнет по производительности на второй тысяче пикселов при попиксельной обработке.
Я бы попробовал на время зума фильтр Blur на минимуме включать. Если он только тоже провернет это дело.
А скорее - отказался бы от плавного зумирования картинки, ведь судя по примеру, все равно фиксируются только крайние состояния, а между ними зум - только в качестве transition. Ну я бы другой транзишн и сделал - от масштабируемой рамочки а-ля фотошоп до "трехступенчатого" зума - т.е. трех фиксированных "степеней увеличения" с небольшой задержкой, - если ТЗ позволяет.

И антиалисинг тут не причем.
Эта же проблема присутствует с векторнмыи объектами, я специально проверял.

Сталкивался с этим неоднократно. Особенно в проектах, где требуется доскональная попиксельная точность. Лечил так:
присваивал значение (целое числовое), потом приравнивал этоже значение, но через округление.
Я это отношу к глюку Flash. Ибо даже располагая объект в точных координатах на сцене (через Properties), после нажатия на Enter иногда получаем тоже самое число с 4-мя (а то и более) знаков после запятой. И это не только с координатами так.

но обычно повторное изменение на нормальные координаты и нажатие ентер помогает (хотя не всегда)

Именно это и иллюстрируется кодом в приведенном мною посте выше ;)

Понятно.
Я советую посмотреть в этот момент на значение _xscale для _width или _yscale для _height. Когда я тестировал, у меня они имели цельные значения. Учитывая, что данные свойства являются геттерами/сеттерами, мы не знаем, что именно происходит в момент присваивания ширины/высоты. Возможно, при больших размерах, происходит округление процентных размеров, а не пиксельных. Отсюда и глюк.

Так векторные объекты *на монитор* выводятся _растром_. Для антиальясинговых проблем вообще неважно, каким образом получены цвета пикселей - это проблема вывода на устройство.

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

PS. Попробуйте, коллеги, плавно и медленно отзуммировать серую линию в 1 px на черном фоне _любым_ способом (хоть прямым выводом в видеопамять :) ) без антиальясинга - увидите, о чем я...