Basically functional in opengl branch.

Other stuff;

1. can OpenGL do the final scale and colourspace conversion (LUT) rather than the CPU?
2. does it work on not-Linux?
3. #if 0 stuff in that branch (mostly swaroop)
4. vsync?

Works on OSX, not Windows; seems to be because glTexImage2D has limitations on the size (either too big or not a power of 2).

Would be interesting to make GLView take a PlayerVideo (rather than an Image) and do the scaling and compositing using GL.

Is there a chance we get a better player performance for many cores/high resolutions in 2.14? It seems there is a serious bottleneck in the current implementation. I rarely work on high res displays, but it seems there is something weird happening.
I have seen some of the current player logs, but can't read much out of it ('delayed'). I was hoping to get an idea about:

• how much time it takes to decode a J2K frame
• how much time it takes to scale it to display resolution
• how much time it takes for the color conversion
• how much time it takes to actually draw the image to the screen
  I would think that, except maybe for the final display, all of these operations can run multithreaded per frame.

I somehow suspect the final display writing as the bottleneck (as it appears the issue is somehow correlated to higher res displays), but maybe I am on a completely wrong track here. Maybe there is something going on with a higher number of threads/cores.

@carl some timings on my mac mini

DrawBitmap: 50ms
wxBitmap::wxBitmap: 15ms
Draw masking etc.: 5ms
wxImage constructor: 0.1ms

I added some basic timing to version 2.15.0, which you can find here

https://dcpomatic.com/test-download?v=2.15.0

After playing some stuff, go to Tools -> Timing and a window is displayed with timing info. It would be interesting to see what you get on any Macs you have around (especially high-res and/or high-CPU-performance ones).

If we can find a simple-ish cause of the slowdown in 2.15.0 I am happy to backport to 2.14.x. An opengl renderer may be a bridge too far, though. That being said, I'm hopeful that the release cycles will get shorter from now on.

Ah, that's interesting, will give it a try.

• Carsten

Can you tell us what these different timings mean?

get() calls is the number of times a new frame has been requested since program start.

The other things are all timings. The first number in the row is the number of seconds (total) spent doing that thing. The second number is the count of times that thing has been done. The third number is the time in seconds per call.

paint-panel is putting the image onto the screen. This seems slow on OS X (hopefully OpenGL might help)

refresh-panel should be very quick; if it's more than 1ms something very strange is happening.

get-image is time spent preparing (scaling etc.) the image in the main thread. If this is low it suggests that the background threads had time to do the preparation before the image was needed (so the main thread had nothing to do, which is the ideal). If is tens of ms it suggests that the background threads are overloaded (i.e. we are CPU bound).

ImageChanged should always be very quick, I just put that in to check.

@carl using wx-3.0.3 branch of mxe to allow WX_GL_MAJOR_VERSION attribute to wxGLCanvas; then trying to force v3 to get more allowed texture sizes. 1024x1024 works.
WX_GL_MAJOR_VERSION -> 3 makes no difference.

@carl looks like just the VM not supporting OpenGL2; ok on laptop. Making opengl2 branch with tidied-up version; investigate why paint never happens in GLView during a PH drag (does it happen in simple? simple updates much more responsively...)

Initial steps are now in v2.15.x.

Seems to work for me, but on my specific MacBook, don't see a difference to 2.14.x (it was performing good before). A simple test shows slightly better fps in OpenGL in full res than 'simple'. I will ask a friend to test it on her Retina Mac Book, which is a nightmare so far.

See timings. This is for a flat DCP at half decoding resolution, playback with zero dropped frames on this machine. Here, clearly J2K is the bottleneck, not drawing.

• Carsten

I guess I wasted my timing results with player 2.15 on a Retina MacBook here:

https://dcpomatic.com/mantis/view.php?id=1546

Carl - why does the timing window sometimes show a 'paint panel row', and sometimes not?

• Carsten

How do you mean "wasted my timing results"?

The paint-panel row got lost in the GL patch; it should be back in 2.15.2.

Currently OpenGL is only used for the final blit; hopefully I can get it to do the scale as well, which should free up some CPU time and hence allow more J2K decoding to happen per second...

Really wondering what is so special about these Retina MacBooks and 5k displays. Yes, more pixels, but not so much more that you would think it costs so much performance. Could it be the OS X version? I can't remember what this 5k iMac ran. I think El Capitan.
The two Retina MacBooks both ran HighSierra.

Remember, that i7-6coreHT MacBook could not even preview BigBuckBunny.mov source without serious frame dropping in DCP-o-matic.

• Carsten

'How do you mean "wasted my timing results"?'

I meant it probably went to the wrong bug entry. I now created relationships, as they all have something in common about the current drawing performance.