On Mon, 13 Sep 2021 07:11:02 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> > in a normal state (when the window is created) we don't need to flush the > > layer content faster than DisplayLink provide. > > But this is exactly related to the performance, no? When the RenderPerf test > is executed it should check that delay between fillRect and the actual > rendering is as small as possible. Can you please just confirm that the > problem is in the "performance" of DisplayLink and unrelated to some broken > rendering? I guess you can create two timestamps in NSWindow creation and in > Layer callback(where we actually blit the content/ drawInXXXContext). How > that timing is different for metal and OGL? I did some measurements for Metal and OGL and didn't find any noticeable difference with the simple test (just showing the frame) Metal 1631605170711 window appeared 1631605170723 rendering submitted 1631605170724 rendering complete 1631605170747 rendering submitted 1631605170747 rendering complete OGL 1631605401836 rendering complete 1631605401838 rendering complete 1631605401843 window appeared 1631605401881 rendering complete Metal has additional output because we can track two stages - submission and completion. Also, I saw the flickering with OGL too (if we have no match with content and window colors) ------------- PR: https://git.openjdk.java.net/jdk/pull/5373
