On Tue, 10 Mar 2020 11:13:54 GMT, Frederic Thevenet <github.com+7450507+ftheve...@openjdk.org> wrote:
>> ### 15-internal: >> >> -------- >> | | 1024 |2048 |3072 |4096 |5120 |6144 |7168 |8192 |9216 | >> |---|---|---|---|---|---|---|---|---|---| >> | 1024 | 5.381051 | 9.261115 | 14.033219 | 20.608201 | 26.159817 | 33.599632 >> | 36.669261 | 43.042338 | 46.086088 | >> | 2048 | 9.752862 | 17.698869 | 27.004541 | 38.437578 | 52.297443 | >> 60.757880 | 68.101838 | 80.162117 | 93.852856 | >> | 3072 | 15.564961 | 27.304138 | 40.255866 | 56.636476 | 80.472402 | >> 86.346635 | 105.154089 | 121.048263 | 130.458981 | >> | 4096 | 19.436113 | 35.556343 | 53.277865 | 71.623899 | 95.814932 | >> 122.543003 | 136.833771 | 160.199834 | 178.356125 | >> | 5120 | 27.246498 | 65.875784 | 73.171492 | 103.380029 | 126.486761 | >> 147.666102 | 165.833885 | 199.005331 | >> 220.659671 | | 6144 | 31.843301 | 62.101937 | 93.646729 | 125.531512 | >> 150.914608 | 175.553034 | 209.835003 | >> 241.114596 | 253.512648 | | 7168 | 40.507918 | 70.843435 | 101.075064 | >> 137.284040 | 165.808501 | 197.015259 | >> 254.286955 | 304.928104 | 299.992601 | | 8192 | 43.206941 | 80.290957 | >> 121.946965 | 157.016439 | 193.509481 | >> 243.514969 | 268.151933 | 359.562281 | 352.102850 | | 9216 | 49.529493 | >> 90.895186 | 149.422784 | 179.512616 | >> 217.260338 | 267.610592 | 309.706685 | 354.950852 | 383.275751 | >>  > > I've uploaded 3 sets of results, from 3 different implementations: > > 1. **14-ea+9** is the implementation merged into openjfx14 following #68; it > only use tiling if the original > implementation fails; on Windows that would typically be when the snapshot > dimensions are larger than 8192 pixels. > 2. **14-internal** uses the same tiling implementation than the above, but > start using tiling as soon as snapshot > dimensions are larger than `PrismSettings.maxTextureSize`; i.e. typically > 4096 pixels. NB: This implementation was > never merged into openJFX; results are only provided for comparison's sake. > 3. **15-internal** uses the tiling implementation proposed in the PR. > Compared to the ones above, it attempt to align > pixel formats to avoid the cost of transformation from one format to another > (e.g. ByteBRGA to IntARGB) and it tries to > divide up the final snapshots into tiles of the same dimensions to prevent > creating a new GPU surface for every tile. > **Please note that these results are for the best possible scenario with > regard to the above optimizations; in the worst > case scenario (a user provided image with a different pixel format and no > way to divide the snapshot into equal size > tiles), then the performances are the same as that of implementation 2** > > My conclusions from the above results are twofold: > > - Tiling has a cost in terms of performance, but as far as I can tell it > remains the only practical way to work around > the underlying issue (i.e. taking snapshot larger than the supported > texture size) and the optimizations proposed in > this PR arguably do mitigate that cost, even if it is only true in some of > the cases. > > - The original implementation, which is preserved in 14-ea+9, ignores texture > clamping to 4096 which means it doesn't has > to resort to tiling until the target snapshot size is >8192 on d3d or 16384 > on es2. > If this is an incorrect behaviour on the part of the original implementation > (which I'm led to believe is the case), it > gives it an unfair advantage in this benchmark, i.e. it is faster because is > does things it shouldn't do. If however it > turns out it is actually safe to ignore clamping when taking snapshot, then > it would make sense to do so in the > implementation proposed by this PR as well. By the way, the code for the above benchmark is available here: https://github.com/fthevenet/snapshot-perf-meter Would it make sense to include it into the OpenJFX repo, maybe under jfx/apps/performance ? ------------- PR: https://git.openjdk.java.net/jfx/pull/112
