JavaFX - Game l oop canvas с высокой загрузкой процессора - PullRequest
2 голосов
/ 10 февраля 2020

Я работаю над простой JavaFX 2D-игрой и сталкиваюсь с проблемами с производительностью .

Я рендерил свою игру на холст, который обновляется каждый кадр. Но обновление холста со скоростью 60 FPS сильно увеличивает мое использование процессора и, конечно, мое использование графического процессора .

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

Основываясь на моих исследованиях, я использую TimeLine для реализации своей игры l oop. Кажется, это лучший способ обновить холст с частотой кадров, которую я хочу:

private void initGameLoop()
{
    final Duration oneFrameAmt = Duration.millis(1000/60);
    final KeyFrame oneFrame = new KeyFrame(oneFrameAmt, actionEvent ->
    {
        gameView.getRenderer().render();
    });

    gameLoop = new Timeline();
    gameLoop.setCycleCount(Animation.INDEFINITE);
    gameLoop.getKeyFrames().add(oneFrame);
}

В этой конфигурации я запускаю свою игру l oop со скоростью 60 FPS, и изменения выполняются на поток приложения FX.

Моя функция рендеринга очень проста:

public void render()
{
    gc.clearRect(0, 0, 50, 50);
    gc.setFill(Color.BLACK);
    gc.fillRect(0, 0, 50, 50);
}

gc - это graphicsContext2D моего холста.

My canvas масштабирует размер окна моего приложения, но я просто перерисовываю черный прямоугольник размером 50x50 каждый кадр, при 60 FPS загрузка моего процессора увеличивается на 8-10% при размере окна по умолчанию, но на полном экране Использование ЦП увеличивается на 25% до 30% , что безумие.

Работает аппаратное ускорение, помимо использования моего ЦП, использование моего графического процессора составляет около 30%.

Я не могу просто прекратить рендеринг холста, когда в игре ничего не происходит, потому что мне нужно рендерить свои анимации.

И в основном перерисовка только частичных областей холста ничего не меняет, потому что мои основы c тест (показанный выше) только перерисовать Прямоугольник 50x50 пикселей в левом верхнем углу холста, и он все еще использует 25% + ЦП.

Все примеры игры l oop или анимации, выполненные с помощью JavaFX, которые Я обнаружил, что в Интернете используются одни и те же методы, но все, что я до сих пор пробовал, имеют высокую загрузку ЦП.

Мой рендеринг очень плавный и плавный, но использование ЦП слишком велико для того, что он делает , Кажется, я не могу понять, почему выполнение такого небольшого количества занимает так много времени на моем процессоре и графическом процессоре и не может найти решение о том, как улучшить мои игровые характеристики. Из того, что я нашел в своих исследованиях, холст кажется лучшим способом визуализации игры в JavaFX.

Мои вопросы: Есть ли способ улучшить производительность с помощью холста? Должен ли я использовать граф сцены с несколькими элементами? Или есть какое-то решение, о котором я пока не думаю?

Спасибо за вашу помощь!

1 Ответ

0 голосов
/ 10 февраля 2020

Концептуально рендеринг JavaFX всегда имеет процессор и часть графического процессора. В части ЦП геометрия подготовлена ​​к визуализации, а часть ГП наконец выполняет рендеринг. Рендеринг холста - самый медленный вариант, потому что API вынуждает вас всегда создавать новые объекты в каждом кадре, когда вы хотите что-то изменить, а это означает, что вы всегда страдаете от медленной части процессора рендеринга. С другой стороны, рендеринг графа сцены может быть быстрее, если изменения, которые вы применяете к вашей сцене, являются только трансляционными преобразованиями (которые могут быть расширены до поворотов и масштабирования с помощью соответствующих подсказок рендеринга), потому что тогда вы страдаете от медленной части ЦП только один раз, но не в каждом кадре. Если вам постоянно приходится менять геометрию, то вы потеряете оба аппроксимации, и единственный вариант - go для 3D-рендеринга (что я и делаю) через треугольник me sh. Приятно то, что в JavaFX 3D-рендеринг можно легко комбинировать с 2D-рендерингом, чтобы получить лучшее из обоих миров.

...