0

We are currently using the cobalt 13.108984 build and are using the DirectFB implementation for a MIPS STB platform.

We are currently implementing our starboard player and we are using kSbPlayerOutputModePunchOut. Currently we are not getting the punch through of the DirectFB graphics plane to the video plane.

I can see that the PunchThroughVideoNode is created in the render tree when the player is created and there is a call into our player to SbPlayerSetBounds with the correct dimensions however the punch through is not successful.

Does the SetBounds call need to update the graphics plane to force the blitter to clear the video rectangle?

Patrick Atkins
  • 23
  • 3
  • Hi Patrick, is it possible that drawing with blending disabled is not implemented on your platform properly? When the rasterizer encounters the PunchThroughVideoNode, it will (in addition to calling SbPlayerSetBounds()) disable blending and draw a rgba(0,0,0,0) punch through rectangle on top of whatever is currently there, but if blending is enabled for this, it will result in no pixels being modified and no window being made. – Andrew Top Nov 08 '17 at 17:17
  • Hi, We have previously been using QT webkit 5.5 on top of the same DirectFB implementation without issue. I will look into testing if there is any issue and also look into comparing the calls to enable/disable blending between QT and cobalt. – Patrick Atkins Nov 08 '17 at 22:09
  • The issue may not be with the blending, I just wanted to try to narrow it down. This is the file responsible for translating from Cobalt's Blitter API to DirectFB calls, and you are free to copy and modify it as necessary: https://cobalt.googlesource.com/cobalt/+/master/src/starboard/shared/directfb/blitter_internal.cc . Please note that I can verify that punch through *is* working properly on that version of the code for an internal DirectFB platform we have over here. – Andrew Top Nov 09 '17 at 02:44
  • 1
    Hi Andrew, thanks for the assistance, it turned out to be a directfb issue, a call into directfb SetVideoMode within window_internal.cc was causing the loss of transparency on the primary layer. Still not sure why but we don't need the call so it is fine to remove it. – Patrick Atkins Nov 10 '17 at 18:56
  • Ahh, weird. Okay glad to hear it's resolved, and thanks for the update! – Andrew Top Nov 14 '17 at 01:12
  • Patrick, I encourage you to repost your comment as the answer to your own question, perhaps it'll help someone else. – mmotorny Nov 16 '17 at 23:38

1 Answers1

1

The solution to my problem was to disable the call to directfb->SetVideoMode() in the window_internal.cc file. This was causing the transparency of the primary directfb layer to be disabled.

This is most likely a bug in the platform driver that we are using (Broadcom 7405 DirectFB 1.4.7 running on top of the Broadcom surface compositor on Reference Software 15.2)

Patrick Atkins
  • 23
  • 3