Я использовал этот метод для съемки экрана.
void takeScreenShotMethod(){
try{
Thread.sleep(10000)
BufferedImage image = new Robot().createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()));
ImageIO.write(image, "jpg", new File("./target/surefire-reports/screenshot.jpg"));
}
catch(Exception e){
e.printStackTrace();
}
}
Вы можете использовать этот метод там, где требуется.
На самом деле вы должны визуализировать много промежуточных кадров и смешать их в один результат. Скажем, например, что ваша выходная частота кадров составляет 50 кадров в секунду. Вы, вероятно, получите разумный результат, если бы выполняли внутренний рендеринг со скоростью 500 кадров в секунду и смешивали группы из десяти кадров вместе, прежде чем показывать это пользователю.
Подход, который вы используете в настоящий момент, имитирует постоянство, как если бы вы рендерили старый ЭЛТ с медленным люминофором. На самом деле это не то же самое, что размытие в движении. Если продолжительность кадра составляет 20 мс (1000/50), то кадр с размытым движением состоит из визуализаций, охватывающих длительность кадра 20 мс, все с одинаковым альфа-взвешиванием. Решение с сохраняемостью состоит из визуализаций 20, 40, 60, 80, 100 мс назад, постепенно исчезающих.
Может быть, совсем не очень резкий. Все зависит от используемой функции наложения. Например, 0,1 / 0,9 для предыдущего / текущего изображения соответственно даст некоторый слабый след.
Я мог бы добавить, что, по сути, это то, как выполняется размытие движения в OpenGL (через буфер накопления)
Насколько мне известно, нет реального способа сделать это более эффективно. Это настолько эффективно, насколько это возможно. Это выглядит неплохо, если частота кадров хорошая, а движение тоже не слишком резкое.
Лучше всего для каждого пикселя нарисовать полупрозрачную линию от нового положения к старому. Однако это нетривиальный расчет.