JDK-8090206 : Mac: GuiMark2 Bitmap runs at 3 fps with non-rectangular clips even after RT-30107
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u40
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-07-14
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8098079 - NGCanvas should take advantage of new 1-step clip support
Relates :  
JDK-8088687 - [Macos] [canvas] Performance problem with Canvas shaped clipping on Mavericks
Description
1. Run GuiMark2 Bitmap test (e.g. I run it as a part of run-subset.sh).

2. There's a button at upper-right corner with text "NOCLIP"

3. Press the button a few times. Observe that as long as the clipping is rectangular, the fps rate is okay (~70 fps). As soon as we switch to oval clipping, the fps rate drops to about 3 fps on my Mac.
Comments
Another interesting observation: 1. With the BitmapTest i get consistent 3 fps regardless of the OVAL clip size. 2. With the VectorChartingTest, however, the results are different: NOCLIP: ~22 fps RECT: ~ 22 fps OVAL: ~ 17 fps SMALLOVAL: 37 fps Note the increase in fps with the SMALLOVAL clip.
18-08-2014
I am looking at some micro-benchmarks to see what might be different - this is mostly in conjunction with the 10.8 vs. 10.9 discrepancies documented in RT-37957 that are likely related to the discrepancies reported here. I wrote a test that draws thousands of ImageViews with either the same image or alternating images and found that I get a 10x performance improvement by batching the images, but I get the same performance differential on both 10.8 or 10.9 so that doesn't represent anything "different" in Mavericks. Next would be to find a way to measure the performance impact of switching destination images, though that is harder to implement as a test case written in FX...
22-07-2014
I think I agree that in large part the low fps could be related to the slow hardware - after all, the Mac-mini is from 2010 or 2009. Still, it is interesting to understand why RT-30107 didn't have any effect on the oval clipping performance on this Mac.
17-07-2014
> Can you run the same test under Windows on the same machine? It's a Mac. I don't have Windows installed on it. > I just looked at the time stamp on build #1064 - 1am on Monday July 14th That's when I've filed this bug. When I've retested this with #1074, I've seen absolutely no improvements vs. #1064. The results with both builds are identical: 70 fps with rect clip and 3 fps with oval clip. So whatever those fixes were, they have not affected this particular issue. > ...after the fix for RT-30107. That, to me, is more of an issue... Exactly. I'll update the Environment shortly so as to indicate that the bug is applicable to the post- RT-30107 world, too. > Is there a reason this mac is on 10.8.2 instead of 10.8.5? I haven't run System Update for a long time to avoid any updates-related disturbances (specifically, to avoid Xcode updates, etc. because I need a stable development environment). I might update it in a few months, but not now.
17-07-2014
I just looked at the time stamp on build #1064 - 1am on Monday July 14th. The best fixes for clipping weren't pushed until the afternoon of July 14th and that build pre-dates those fixes. The speeds you are seeing are not necessarily out of line prior to the most recent fixes. It looks like you also tested on a build that had the fixes in it and got the same performance. The question now is why you saw similar performance before and after the fix for RT-30107. That, to me, is more of an issue than the fact that the demo gets slow performance with clipping in the first place. As it stands, the bug is tagged with a synopsis and environment that simply point out slow performance of clipping pre-30107, which is not unexpected.
16-07-2014
Is there a reason this mac is on 10.8.2 instead of 10.8.5?
16-07-2014
Yes, we are working on that. On most machines the work already done has sped it up to only about 3x slower. There may be more to do, but it would involve a fair bit of upgrades to the graphics architecture. We still have an unknown effect whereby 10.9 negates most of the gains even on machines with GPUs that saw a huge gain under 10.8. Solving that mystery may help with the weaker/older machines as well. Time will tell. Can you run the same test under Windows on the same machine?
16-07-2014
Why should it run very slowly with non-rectangular clipping? I realize it might run slower than with rectangular clipping, but not 20x times slower... This just doesn't seem right.
16-07-2014
It's running es2, not sw pipeline.
16-07-2014
GPU: NVIDIA GeForce 9400 256 MB
16-07-2014
Just to be clear - we expect the demo to run very slowly with shaped clipping. That's why this control was added - to improve those times - and we have already made a few improvements. Which GPU does that mini have? It may just not be powerful enough to do this shaped clipping very well. Also, which pipeline does it run with? The improvements won't do much for the sw pipeline until/unless that pipeline implements the MaskTexture calls that are needed for the 1-step clipping. Another comparison is against 8u20. We should be at least a little faster than 8u20, but YMMV there as well depending on the power of the computer.
16-07-2014
I'm running OS X 10.8.2.
16-07-2014
I filed RT-37957 to track the issue with Mavericks.
16-07-2014
What version of MacOS? We are seeing performance problems with this clipping on Macs running Mavericks.
16-07-2014
I've just downloaded the latest build from Hudson (8u-dev, build # 1074, built Jul 16 3:16 PDT) and the bug is still there: the GuiMark2 runs at 3 fps as soon as I switch to the OVALCLIP, as opposed to normal/rectclip running at ~70 fps. I'm not sure if this is OK.
16-07-2014
Please verify performance after fix for RT-30107. There's not much more we can do beyond that (note that this issue - measuring RT-30107 - was the reason I added those controls to the toy in the first place... ;)
15-07-2014
GuiMark2 HTML5 Vector Test is also affected, but somewhat less significantly (the fps drops from ~22 to ~15).
14-07-2014