Баги
Запись от Gladreaman размещена 20.05.2009 в 21:40
Тут буду выкладывать все баги флэша, которые встретил.
Вопервых, это ненавистный scrollRect и scaleX(Y). С их помощью, оказывается, невозможно увеличивать до бесконечности подгруженный мувик. Даже если он большой плотности. И все дело в том, что scrollRect понимает только целочисленные, больше 1ы. И это плохо. Например, если на карте нужно найти галлактику, затем планету, затем город и дом, то это нужно делать кусками, или еще как. А при большой детализации (выше 1го пикселя), scrollRect вообще не работает.
Вовторых, когда я делал свой класс для Hinta, а это мой глюк, а не флэша, я по ошибке не лиметировал значения textField'а, в итоге хинт работал весьма напряжно, ибо когда я подводил мышу к кнопке, выскакивал хинт, а затем незаметно перекладывал на себя фокус мыши, затем исчезал (бо так я прописал ему), затем выскакивал заново и т.д. Сие мерцание меня бесило аж 3 часа, пока я не нашел что к чему. Посему будьте внимательнее с textFieldом!
Втретьих, это глючный htmlText у текст фильда на момент подгрузки аштэмэля. И все дело в том, что картинки и мувики он грузит весьма напряжно, отдельно от самого html. В итоге возникает резонный вопрос о действительной высоте сего творения. И без getImageByReference не обойтись. В итоге полный комплект, без бага, состоит в том, чтобы пропарсить html текст, добавить айдишники к каждому <img тагу, не наделать при этом ошибок, а затем по getImageByRef отслеживать догрузку каждой картинки, дабы воспринимать действительность такой, какая она есть, а не такой как хотелось бы.
Всего комментариев 3
Комментарии
26.05.2009 21:46
|
|
|
http://groups.google.com/group/ruFla...23244c565af814
На всякий случай копирую аналитическую статью автора prof, если ссылка не будет работать. Он пишет: В очередной раз игрался с битмапами и в очередной раз натолкнулся на эту проблему. Наталкивался и раньше, но обходил с помошью эмпирически найденного способа. А в этот раз решил покопать глубже, и кое-что накопал. Итак, проблема выражается в том, что при определенных условиях метод draw класса BitmapData не работает. То есть, в целевом битмапе никаких изменений не происходит. Было понятно, что это как-то связано с параметрами, передаваемыми в метод. Путем несложных экспериментов выяснил, что на возникновение проблемы влияют двевещи: размер исходного битмапа и масштаб. Допустим, наш исходный битмап имеет размер X на Y. Коэффициенты масштабирования по осям - kx и ky. Метод draw работает на ура, если одновременно выполняется: kx*X < 8192; ky*Y < 8192; Поскольку 8192 == 0x2K, мы решили для себя называть эту проблему именно так, как написано в subj. Все остальные параметры никак не влияют на работоспособность метода draw (по крайней мере, я ничего такого не обнаружил). Предвосхищая возможные посылания меня в хэлп, где написано про ограничения в 2880 пикселов на размер BitmapData, говорю, что это тут ни при чем. Дальше - больше. Выяснилось, что если дальше увеличивать размер исходного битмапа и/или масштаб, то метод draw снова начинает работать после какого-то момента. Новые нехитрые эксперименты позволили понять, что на самом деле метод работает, если одновременно выполняются снова два условия, но немного другие: 2*i*0x2000 < kx*X < (2*i + 1)*0x2000; 2*j*0x2000 < ky*Y < (2*j + 1)*0x2000; Здесь i, j = 0, 1, 2... Можно это условие выразить и по-другому: (int(kx*X) & 0x2000) == 0; (int(ky*Y) & 0x2000) == 0; То есть, в результате умножения размера и масштаба, приведенному к целому типу, 14-й бит отвечает за работоспособность метода draw(). Вот такая вот проблема. Никакой информации в сети относитально нее я не нашел, поэтому слезно прошу тех, кто знает о наличии таковой, сообщить. Ну или тех, кто просто встречался с этой проблемой. Может быть, кто-то знает причины возникновения такого явления? Мы предполагаем, что это баг, а не фича, и заключается он примерно в том, что кто-то по ошибке использует 14-й бит в качестве знакового (это просто - вместо сдвига на 24 бита сдвинули на 14). В общем, мнения - в студию! -- prof |
|
27.05.2009 02:01
|
|
|
зайди что-ли на багрепортер адобы или флекса.. там много всякого)
|
|
09.07.2009 15:09
|
|
|
про вопервых - то что ты собрался делать кусками называется мип меппингом, и предоставляет больше положительных сторон, нежели отрицательных (ускоряет работу приложения, уменьшает размер необходимых данных[в галлактике есть много черных кусков которые запоминаются простыней, а это плохо], улучшает катчество изображения избегая интерполяцию).
про втретьх - зачем тебе такие ужасы??? оО |
Последние записи от Gladreaman
- Баги (20.05.2009)
