Expected frame rates for a full-screen blur

[Richard Bair]

You might also want to try using the PulseLogger (which was recently refactored to be usable from Java Flight Recorder). See http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/978e5c042214/modules/base/src/main/java/com/sun/javafx/logging/PrintLogger.java. Basically a few system properties are needed and then you should get per-pulse data that breaks down the time spent in different places. It seems like it shouldn’t be the case, but it looks like you’re fill rate limited. Maybe we are sending really huge bitmaps down to the card and the card bus just can’t keep up?

-Djavafx.pulseLogger=true

On Apr 4, 2014, at 2:17 PM, Stephen F Northover <steve.x.northover at oracle.com> wrote:

> Hi Mike,
> 
> I'm sorry that I've been unable to get to this until now.  I can recreate the problem you are seeing on my Mac by running ColorfulCirclesApp.  Please enter a JIRA for the problem.  Thanks. Also try this:
> 
> Try this:
> 
> PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
> Timeline timeline = new Timeline(
>  new KeyFrame(Duration.seconds(1), t -> {
>     System.out.println("::FPS = " + tracker.getAverageFPS());
>  }));
> timeline.setCycleCount(Timeline.INDEFINITE);
> timeline.play();
> 
> Steve
> 
> On 2014-04-04 4:33 PM, Mike Hearn wrote:
>> OK, now I'm really puzzled - I watched the JavaFX performance talk from
>> 2011 and learned about PeformanceTracker. It's too bad that's not public
>> API, but it works. I used it like so:
>> 
>> PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
>>         tracker.setOnRenderedFrameTask(new Runnable() {
>>             long lastTimestamp = System.currentTimeMillis();
>> 
>>             @Override
>>             public void run() {
>>                 final long now = System.currentTimeMillis();
>>                 long delta = now - lastTimestamp;
>>                 if (delta < 1000)
>>                     System.out.println("Frame took " + delta + "msec");
>>                 lastTimestamp = now;
>>             }
>>         });
>> 
>> The 1000 thing is just to avoid printing a nonsense timestamp when the UI
>> hasn't been touched for a while.
>> 
>> The deltas I see are consistently between 10-20msec which would be between
>> 50 and 60fps, i.e. the vsync of the screen. But the wacky thing is, this
>> doesn't change when I increase the size of the window, even though the
>> animation is noticeably more choppy. It still says there's a 10-20msec gap
>> between frames even though my eyes tell me otherwise. Even when I shrink
>> the window size right down and get super smooth animation, the above code
>> prints the same kind of deltas.
>> 
>> This makes me think that whatever is going on, the regular JavaFX drawing
>> thread isn't the issue. It seems to be churning through the scene at the
>> same totally acceptable rate no matter what. So I'm thinking the issue must
>> be something to do with how fast the GPU drains the command queue or
>> something.
>> 
>> BTW I tried doing -Dprism.order=j2d to see what would happen, and the GUI
>> hangs before rendering anything. I'll file a bug on that later.
>> 
>> 
>> On Thu, Apr 3, 2014 at 11:54 AM, Mike Hearn <mike at plan99.net> wrote:
>> 
>>> How does the OS "tank"?
>>> All the OS animations hit the same frame rate as the app itself does. For
>>> instance, opening Mission Control is normally smooth, but when a maximized
>>> JFX app is animating, it's not.
>>> 
>>> It feels like the GPU is being overworked but as I'm not a GPU expert at
>>> all, I'm not sure where to begin - I am not even sure how to find out the
>>> frame rate so I know when tweaks are improving things! Is there a way to
>>> get this data from the system?
>>> 
>