Суть проблемы в том, что у меня джарик весит около 180 кб. 160 кб из них - картинки... Я, как положено, загружаю их все в память, потом около 20 кб освобождаю...
Так вот, проблема в том, что в начале я некоторые картинки не отображаю, т. е. они лежат себе спокойно где-то в памяти, но когда я их вызываю, то прорисовка изображения занимает примерно сек. 2. Если потом снова загрузить эту же картинку, то она прорисуется быстро...
Кто знает, что это за полтергейст? И можно ли как-то ускорить процес прорисовки?   

M W0LF

как-то, но надо называть. таких названий пожалуйста больше не давай.

Быть может ты ее прорисовал уже на форме, а потом просто форму подставляешь? кусок кода можешь показать, который отвечает за это?

Больше не буду...

Есть класс ImageManager, в котором все процедуры и Image статические...
В другом классе я их загружаю...



У меня есть методы и побольше, но они прорисовываются нормально... Не пойму, что за бок...

Добавлено через 1 минуту и 13 секунд
Это единственный класс, где выводится это изображение...

я от это не совсем догнал :(
то есть твой метод паинт рисует картинку первый раз на две секунды больше, чем например во второй раз?

Точно. на эмуляторе конечно все рисуется нормально, а на телефоне вот такой бок.

а чему равны SCREEN_WIDTH и SCREEN_HEIGHT?

Добавлено через 2 минуты и 37 секунд
и еще - ты уверен что именно paint() ждет?
поставь в нем время. посмотри скоко времени он занимает первый раз и второй.
может у тя чет происходит перед repaint() что и требует большего времени..
где ты делаешь repaint()?

Для repaint() есть свой отдельный класс WorkCanvas. С ним, я уверен на 100%, все впорядке.
Я поробовал поменять очередь загрузки картинок в программе.
Те картинки, которые я загружаю первыми, отображаются нормально, те что позже - тормозят...
----------------------------------------------------------------------------------------------------------------------------------
И как я смогу проверить время ожидания, если на эмуляторе у меня все прекрасно работает?

Добавлено через 6 минут и 39 секунд
Как и предполагалось, эмулятор показал 0 мс в обоих случаях   

я у тебя еще спросил что с параметрами SCREEN_WIDTH и SCREEN_HEIGHT?
может они на самом деле меньше, чем высота и ширина экрана?
и получается так, что рисунок во второй раз рисуется в меньшую область, а края не затраются а остаются теми же..


и проверь реально на девайсе время первой и второй отрисовок

С SCREEN_WIDTH & SCREEN_HEIGHT у меня тоже все впорядке...
Замеры произвел, в первом случае дало 1132, во втором 1 (или 0)

Добавлено через 2 минуты и 31 секунду
Загрузка другого дала 2150

видишь, получается что в первом случае рисуется наоборот быстрее а не медленнее..

Ты меня не понял,
один рисунок 1-й раз прорисовывался 1132 мс, второй раз - 0мс;
другой рисунок 1-й раз - 2150 мс, второй раз - 0 мс   

Как вариант, что если добавить буфферизацию и сначала нарисовать этот image на mutable Image а потом уже этот mutable image на экран шлепнуть?

Пробовал уже, не помогло...   Все-равно долго прорисовывается...

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

Телефончик SE K700. Никогда не слышал о таких проблемах. И на эмуле K700 у меня все прорисовывается нормально... 

на k700 у мну проблем никада не было..
попробуй GameCanas
он автоматом делает двойную буфферизацию

  У меня реализован класс типа GameCanvas, который тоже отвечает за двойную буфферизацию.
С помощью Memory Monitor выяснил, что у меня постоянно забивается память, возможно из-за этого. Хотя не факт, потому что я могу до бессконечности играть в игру, память будет забиваться, но при этом никаких тормозов не наблюдается...

  Вроде разобрался, легче конечно от того не стало...
Как выяснилось, дело скорее всего в том, что у некоторых моделей телефонов SE есть два типа используемой памяти plain Java Heap & LAM (Large Array Memory).
При работе телефон использует и ту и другую, просто одна - быстрая, а вторая - медленнее... Так вот, сначала ресурсы загружаются в быструю память, а потом, если не хватает места, в ту, что помедленнее... Ну и эта fast video RAM (plain Java Heap, если я правильно понял) имеет размер всего 80 кб.   
Изображения в моем приложении весят 160 кб, соответственно половина уходит в LAM, а потому, когда я к ним обращаюсь для прорисовки, то первый раз на прорисовку уходит 1-2 сек.
И что тут придумаешь теперь?

Попробуй отрисовать через  drawRegion, правда будет только на MIDP 2.0 работать, но там вроде можно задать нужный кусок Image.

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

Да я че-то подумал, может имеет смысл сделать одну здоровую картинку, а не несколько поменьше. Ну и выводить соответственно через drawRegion.

Проблема то в том, что если я зделаю одну большую картинку из всех, что у меня есть, то она по-любому будет больше 80 кб., а в доке по Сони Ериксон я извлек то, что быстрая видео-память имеет размер 80 кб. Отсюда, или нужно каждый раз одни рисунки выгружать, а другие загружать, или мириться с тормозами. Другого выхода я пока не вижу...   

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

У меня тоже SE поэтому интересно стало. 
Нашел я описание 
http://developer.sonyericsson.com/getDocument.do?docId=65067

Там сказано:

Java heap
Java applications use two kinds of heap memory,plain Java heap and LAM (Large Array Memory).The
LAM is shared with other processes on the phone. Standard Java objects and vectors of Java objects are
always located on the Java heap. Arrays of primitive types (byte[] int[], float[]) however may be
put in the LAM if the plain Java heap is low on memory. Small arrays have a greater chance of ending up
in the plain Java heap,while large arrays more often are stored in the LAM. 
!!!
Images are also sometimes placed in LAM. 
!!!
The size and configuration of the Plain heap size and the LAM size varies between phone models.

Note:From JP-7 Sony Ericsson phones only have one java heap area,which grows dynamically,only lim-
ited by free memory in the phone.

!!!
The size of LAM is not included in the values reported by 
Runtime.freeMemory and
Runtime.totalMemory
!!!

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