проверку своей программы я проводил на nokia 5500d - s60v3, nokia 6680 - s60v2, Nokia 9300i - s90, Siemens CX65, Motorola e398, Nokia e50, Nokia 2630 и плохие результаты, вернее скажем всего 20 кадров в секунду минимум были на Siemens CX65, Motorola e398 и самая катастрофа была на Nokia 2630
а почему Вы спросили?? что с этой платформой что то не так?

Одно время были проблемы с Nokia S60 2 Ed.
Жутко тормозил flushGraphics();

Оказалось тормозила связка drawRegion() + flushGraphics();

Вопрос решил использованием Nokia API DirectGraphics

Вообщем совет на эту платформу такой: использовать MIDP 1.0 + Nokia API

на какую имено платформу?? подтормаживает то и на сименсах и на мотороле
а вот интересно нокия 2630 потдерживает nokia API или только MIDP 2.0 и что еще быстрее на ней работать будет...

Для Нокия S60 2 Ed




Если на всех подтормаживает, то что-то с кодом не то. 
Выложи код - посмотрю.




2630 - новый телефон, даже если и есть нокия АПИ, то лучше МИДП 2.0 использовать.

да с кодом то все в порядке  сам код(то есть просчет и все действия, и даже прорисовка в двойной буфер) быстро выполняется, 6-7 мс на медленных телефонах, все время занимает функция flushGraphics();. а пробовать вызыпать flushGraphics(int,int,int,int) лишь еще замедляется дело...
просто думал может как то можно обойтись без, скажем если через MIDP 1.0 делать, потому что дело полностью в ней :(

Из ваших слов можно сделать вывод, что с кодом у вас не все в порядке.
Если используется flushGraphics() значит у вас есть класс extends GameGraphics, а этот GameCanvas сам по себе имеет двойную буферизацию, а вы говорите, что дополнительно еще прорисовываете в двойной буфет. Или я не прав?

Свой пример я привел: по все показателям замера времени тормозил flushGraphics() на Nokia S60. Когда же убрал drawRegion() и заменил на аналог в Nokia API: после этого flushGraphics() перестал тормозить. Игра стала летать.

Как обойтись без flushGraphics()? 

shomer кажется привел пример, как это сделать использую Canvas:

нет еще одного двойного буфера нету, я подразумеваю двойную буферизацию которая реализована в GameCanvas.
а если не секрет то что делает функция drawRegion()?
я знаю как реализовавать самопальную двойную буферизацию, просто я интересовался в первом посте, будет ли это быстрее работать? там же я и предложил 5 вариантов как можно отрисовывать сцену 
просто обидно, игра потенциально может работать очень быстро, а из за одного вызова функции flushGraphics тормозит...

Даю 100% гарантии, что причина тормознутости не в flushGraphics(). Даю 100 потому, что сам делал игры "потяжелее" чем шарики с использование flushGraphics() и знаю, что сам по себе этот метод не тормозит.
Портации делались на все указанные телефоны (ну может не совсем эти, но по списку совместимости точно на все). Глюк с тормозами был только на s60.
А если где-то тормозило, то из-за неправильного кода, неоптимальности и т.д... но никак не из-за использования flushGraphics().

Причину нужно искать не во flushGraphics().

Причин может быть много, например, перед тем как нарисовать шарик, ты создаешь Image этого шарика, а потом отрисовываешь и так при каждой отрисовке.   

Без кода можно только гадать..

Так что код в студию или стоит закрывать тему.

ну не надо думать что я программирование занимаюсь  первую неделю или первый месяц, как никак уже почти десять лет  да и алгоритм я специально оптимизировал как мог, там фактически одна математика, и прорисовка drawImage...
а на счет ста процентов, ну не знаю, все таки время то не обмануть, если я провожу замер и вижу, что вся игра выполняется за 7 мс а flushGraphics за 33 то наверное это о чем то говорит.
Конечно может быть летающие шарики можно сделать значительно оптимальнее, неже ли это сделал я, с точки зрения математики, и это я уже начинаю понимаю  и конечно проведу оптимизацию, но это уменьшит цифру 7 мс но не 33 мс 

  

voltaren, я исхожу из того, что Нокия, Моторола, Сименс не могли на стольких телефонах сразу криво реализовать метод flushGraphics(). 
Понимаю, если бы это были какие-то три "корейца"... плюс у меня самого нормально идет приложение.

Поэтому, ты как человек с большим опытом работы в программировании должен понимать, что где-то не с той стороны подходишь к решению своей проблемы. Или ты так не думаешь?

Раз уж ты не хочешь код показывать, то сам подумай: flushGraphics() работает нормально, проблема в другом месте. 

Может у тебя память под завязку занята, поэтому когда flushGraphics() вызывается, то идет вызов сборщика мусора, а он уже тормозит.

Так где же код