The NEWT BCM VC IV on Raspberry Pi provides its own mousepointer and renders OpenGL ES 2 content to a dispmanx surface. This is good for console use. However when the user is using xorg then the user is presented with dual mousepointers as seen in this image: http://forum.jogamp.org/file/n4034929/Processing_3_runnign_for_the_first_time_using_broadcoms_OpenGL_ES2_driver_and_NEWT_on_the_raspberry_pi.jpg The raspberry pi experience can be improved by initializing an xorg window when running inside xorg for each dispmanx surface and let this xorg window handle input. The dispmanx surface should be aligned with the xorg window.
Implementation of Enhancement1178 https://github.com/jogamp/jogl/compare/master...xranby:Enhancement1178
(In reply to comment #1) > Implementation of Enhancement1178 > https://github.com/jogamp/jogl/compare/master...xranby:Enhancement1178 Code review: http://jogamp.org/log/irc/jogamp_20150723050525.html#l158 (03:43:22) xranby_: i will cleanup the commits, fix whitespace and look into some minor bugs discovered (03:46:22) sgothel: - NPE Clicked: check (one commit) (03:48:57) sgothel: "/* pp */public " -> public (03:49:09) sgothel: 'pp' stands for package private, the default access permissions (03:50:03) xranby_: sgothel: since i no-longer need to call those two private init singletons to workaround we can leave them as private (03:50:17) sgothel: just walking through .. (03:50:36) xranby_: but thank you for explaining what the /* pp * / stands for..! (03:50:59) sgothel: so you also track the NEWT X11 dummy (event) window .. ? nice nice (03:51:10) sgothel: i.e. drag it along the BCM window (03:51:21) xranby_: yes when i drag around the newt window then the overlay moves (03:51:23) sgothel: that would have been my next question :) (03:51:34) sgothel: yup .. sort of an underlay X11 NEWT window :) (03:51:52) xranby_: thus the name of the tracker class should be something else than X11MouseTracker (03:51:58) sgothel: and great that you simply solved the factory hassles via reflection (03:52:51) sgothel: so .. it works for both .. mouse/key .. I assume you tested w/ and w/o X11 on raspi .. (03:53:01) sgothel: waiting for your clean patch then .. hurray! (03:53:24) xranby_: yes i have tested both using console and x11 and remote ssh connections with and without -X (03:54:02) sgothel: thoroughly .. KUDOS (03:54:57) sgothel: sure there might be corner cases .. like z stacking (overlapping other windows ..) hmm, we will see (03:55:12) sgothel: other x11 windows .. cascading .. etc (03:55:45) xranby_: i can list some cornercases on top of my head: (03:56:13) xranby_: cc1: if you minimize the X11 window the overlay is still visible (03:57:09) xranby_: cc2: if you move the X11 window outside the visible screen then the overlay gets recentered by bcm.vc.iv code to be inside the screen (03:57:46) sgothel: cc1: how do you minimize it? isn't it w/o frame/decorations? so if not: well, you can handle that via events -> BCM (03:57:59) sgothel: cc2: yeah .. that sucks :) (03:58:15) sgothel: cc2: recenter the x11 window .. -> feedback BCM limits (03:58:59) xranby_: cc3: when you resize the x11 window then the overlay gets resized but get a new position (minor bug in bcm.vc.iv) (03:59:16) sgothel: cc3: fixable .. (03:59:34) sgothel: cc4: another window overlaps NEWT window -> BCM window is still on top (03:59:42) sgothel: cc4: not fixable .. probably (04:00:05) sgothel: so we have our BCM layer always-on-top -> feedback to x11 window to set it on top (04:00:07) xranby_: fix for cc1: can we request the newt window to disable minim9ize button? (04:00:25) xranby_: fix for cc4: can we request the newt window to use allways on top ? (04:00:36) sgothel: cc1: disable minimize: we don't have that yet .. planned feature .. (04:00:45) sgothel: cc1: just set BCM visible:=false (04:00:54) sgothel: cc4: yes (04:01:27) sgothel: setAlwaysOnTop .. :) (04:01:45) xranby_: fix for cc2: move the X11 window to be repositioned according to the feedback limits (04:01:55) sgothel: yup .. as mentioned (04:01:59) sgothel: cool (04:02:13) sgothel: you are the man (04:02:31) sgothel: this way .. w/ NewtCanvasAWT .. well, you know it :) (04:03:22) sgothel: ^^ next step .. i.e. whether the X11 dummy window can be used as child window .. etc (04:03:43) sgothel: for the AWT NEWT integration .. if so desired .. hehe (04:03:44) xranby_: for newtcanvasawt i may look into using some blitting hence bug626 https://jogamp.org/bugzilla/show_bug.cgi?id=626 (04:04:10) sgothel: that would be plain AWT .. via GLCanvas IMHO (04:04:33) sgothel: but then again .. GLJPanel already does blitting (04:05:16) sgothel: hey - having a NEWT BCM/X11 mixup done - great (04:06:11) xranby_: i wanted to reuse the newt events produced by teh newt x11 window but did not manage to get the code working thus therefore i resynthisized new events (04:06:23) sgothel: hmm (04:06:35) xranby_: if i could re-use the x11 newt events as is then it would support multiple mousepointers etc (04:06:37) sgothel: I will look over that .. (04:06:41) xranby_: hence cc5: (04:07:08) sgothel: yup - I can take that part - after your patch (04:07:14) xranby_: kudos! (04:07:33) sgothel: maybe dump all the above CC's to the bug report - thx (04:07:40) xranby_: cc0: -> sgothel: - NPE Clicked: check (one commit) (04:07:50) sgothel: hehe .. yeah (04:08:04) sgothel: never happens w/ current native driver .. but still (04:08:19) xranby_: fix for cc0: can we use a return at line 3001? instead fo the break ? (04:09:22) sgothel: technically sure - I just try to continue w/ the flow .. i.e. avoid premature returns .. just a question of style. (04:09:43) sgothel: do it (04:10:01) sgothel: (i.e. one less branch :) (04:10:23) sgothel: so no need to assign e (04:11:26) xranby_: sould i comment it with /* premature return */ return; to make it stand out in the code when you read it ? (04:12:14) sgothel: as you wish .. I guess it is clear, maybe: '// swallow CLICK event' :) (04:13:00) sgothel: '// Fall through intended!' <- I just drop those .. since reviewer might get confused :) (04:13:29) sgothel: as well as I prefer 'null == a' instead of 'a == null' .. due to typos like 'a = null' :) (04:13:45) sgothel: i.e. l-value in comparison always w/ constant first (04:13:54) xranby_: ah, gotcha! (04:14:03) sgothel: (or final ..) (04:14:43) sgothel: and I use the 'final' like in that long switch block, to ensure that the value is set only once .. so it is a more clear workflow (04:17:51) xranby_: cc5: if you render the bcm.vc.iv window transparent -> caps.setBackgroundOpaque(false); then you will see that the tracker window newer repaints -> looks a bit like a mess (04:18:12) xranby_: sorry cc6: ^ (04:18:22) sgothel: the x11 window can be set transparent as well .. hmm (04:18:43) xranby_: fix for cc6: make the x11 window set to be transparent ^ (04:19:07) xranby_: OR repaint it with somehting dull like gray
Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1178 Bug 1178: Implement X11UnderlayTracker Fixed corner cases cc0, cc4, cc7 and cc8 Bug 1178: Fix cc0 WindowImpl: Swallow CLICK event Bug 1178: X11UnderlayTracker Fix cc4. Attempted fix for cc6. Bug 1178: Fix cc8 bcm.vc.iv WindowDriver: Update pointer during DRAGGED events. Bug 1178: Fix cc7 X11UnderlayTracker can now track multiple windows. Bug 1178: Mouse events shall be passed on to unfocused overlays. Bug 1178: if overlay is undecorated then make under-lay the same Unfixed corner cases: cc1: if you minimize the X11 window the overlay is still visible Fix for cc1 requires that NEWT can send minimize events. cc2: if you move the X11 window outside the visible screen then the overlay gets recentered by bcm.vc.iv code to be inside the screen. Fix for cc2 require that the bcm.vc.iv driver send a new WindowEvent when it have re-centered inside the screen. cc3: when you resize the x11 window then the overlay gets resized but get a new position (bug in bcm.vc.iv driver) cc5: re-use the x11 newt events as is then it would support multiple mousepointers etc cc6: if you render the bcm.vc.iv window transparent -> caps.setBackgroundOpaque(false); then you will see that the tracker window newer repaints -> looks a bit like a mess Fix for cc6 require that the X11UnderlayTracker NEWT windows gets repainted with a transparent color.
Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1178 Included new workaround for cc9: cc9: Pressing Maximize locks-up the NEWT EDT Workaround cc9: Prevent the overlay to re-position the underlay
(In reply to comment #4) > Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1178 > > Included new workaround for cc9: > > cc9: Pressing Maximize locks-up the NEWT EDT > Workaround cc9: Prevent the overlay to re-position the underlay Excellent WIP state - merged!
cc10: Regression caused by the fix for corner case 7. https://jogamp.org/git/?p=jogl.git;a=commit;h=59c278f0c492de37a1e31af7cb9f825353118fe1 Since we no longer try to make a window visible inside the static constructor of the X11UnderlayTracker.java generates a new side effect that we no longer throw an ExceptionInInitializerError that can be caught on line 76 of bcm/vc/iv/WindowDriver https://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/classes/jogamp/newt/driver/bcm/vc/iv/WindowDriver.java#l76 instead we see this new runtime exception when we try to make the X11 underlay window visible when X11 is not available. Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: com.jogamp.nativewindow.NativeWindowException: X11Util.Display: Unable to create a display(nil) connection. Thread main-Display-.bcm.vc.iv_nil-1-EDT-1 at jogamp.newt.DefaultEDTUtil.invokeImpl(DefaultEDTUtil.java:249) at jogamp.newt.DefaultEDTUtil.invoke(DefaultEDTUtil.java:163) at jogamp.newt.DisplayImpl.runOnEDTIfAvail(DisplayImpl.java:427) at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2502) at jogamp.newt.WindowImpl.setVisible(WindowImpl.java:1190) at jogamp.newt.WindowImpl.setVisible(WindowImpl.java:1195) at com.jogamp.newt.opengl.GLWindow.setVisible(GLWindow.java:568) at demos.es2.RawGL2ES2demo.main(RawGL2ES2demo.java:303) Caused by: java.lang.RuntimeException: com.jogamp.nativewindow.NativeWindowException: X11Util.Display: Unable to create a display(nil) connection. Thread main-Display-.bcm.vc.iv_nil-1-EDT-1 at jogamp.newt.ScreenImpl.create(ScreenImpl.java:143) at com.jogamp.newt.NewtFactory.createScreen(NewtFactory.java:217) at jogamp.newt.driver.x11.X11UnderlayTracker.windowGainedFocus(X11UnderlayTracker.java:191) at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:4098) at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:4020) at jogamp.newt.WindowImpl.focusChanged(WindowImpl.java:4142) at jogamp.newt.driver.bcm.vc.iv.WindowDriver.createNativeImpl(WindowDriver.java:221) at jogamp.newt.WindowImpl.createNative(WindowImpl.java:654) at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:1127) at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1181) at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:150) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372) Caused by: com.jogamp.nativewindow.NativeWindowException: X11Util.Display: Unable to create a display(nil) connection. Thread main-Display-.bcm.vc.iv_nil-1-EDT-1 at jogamp.nativewindow.x11.X11Util.openDisplay(X11Util.java:453) at jogamp.newt.driver.x11.ScreenDriver.runWithTempDisplayHandle(ScreenDriver.java:281) at jogamp.newt.driver.x11.ScreenDriver.validateScreenIndex(ScreenDriver.java:241) at jogamp.newt.ScreenImpl.create(ScreenImpl.java:121) ... 11 more
https://github.com/xranby/jogl/commit/36e9671177c690ebd71d93021b8f797487785dda Bug 1178: Fix cc10 regression caused by the fix for cc7. Bug 1178 cc10: We no longer throw an ExceptionInInitializerError when X11 is not available. Fix 1178 cc10: We need to use an X11 resource in the constructor in order to throw an ExceptionInInitializerError if X11 is not available. We can resolve this by query for the X11 display and screen inside the constructor.
(In reply to comment #3) > cc3: when you resize the x11 window then the overlay gets resized but get a > new position (bug in bcm.vc.iv driver?) Captured a log using -Dnativewindow.debug=Window to see what happens during resize first X11(underlay) sends a WINDOW_RESIZED event and .bcm.vc.iv gets resized correctly then happens the unexpected: the X11(underlay) thinks it have moved to a new position and sends a WINDOW_MOVED relative to top left corner + window decorations, a bug in the NEWT X11 Window driver! Window.positionChanged: (main-Display-.x11_:0.0-2-EDT-1): (defer: false) 362/66 -> 1/30 - windowHandle 0x1600002 parentWindowHandle 0x0 definePosition: 362/66 -> 1/30 consumeWindowEvent: WindowEvent[WINDOW_MOVED full log below: Window.focusChanged: (main-Display-.x11_:0.0-2-EDT-1): (defer: false) state [visible, aontop, ] -> focus true - windowHandle 0x1600002 parentWindowHandle 0x0 consumeWindowEvent: WindowEvent[EVENT_WINDOW_GAINED_FOCUS, NEWTEvent[source:jogamp.newt.driver.x11.WindowDriver, consumed false, when:1440416397979 d 0ms]], visible true 362/66, win[362/66 358x283], pixel[358x283] Window.sizeChanged: (main-Display-.x11_:0.0-2-EDT-1): (defer: false) force false, 358x283 -> 348x317, state [visible, focused, aontop, ] - windowHandle 0x1600002 parentWindowHandle 0x0 defineSize: win[358x283 -> 348x317], pixel[358x283 -> 348x317] consumeWindowEvent: WindowEvent[WINDOW_RESIZED, NEWTEvent[source:jogamp.newt.driver.x11.WindowDriver, consumed false, when:1440416397980 d 1ms]], visible true 362/66, win[362/66 348x317], pixel[348x317] Window setSize: START force false, 358x283 -> 348x317, windowHandle 0x67ca4418, state [visible, focused, ] reconfigureWindowImpl want 362 66 348 317 reconfigureWindowImpl rect 362 66 348 317 Window.sizeChanged: (main-Display-.bcm.vc.iv_nil-1-EDT-1): (defer: false) force false, 358x283 -> 348x317, state [visible, focused, ] - windowHandle 0x67ca4418 parentWindowHandle 0x0 defineSize: win[358x283 -> 348x317], pixel[358x283 -> 348x317] consumeWindowEvent: WindowEvent[WINDOW_RESIZED, NEWTEvent[source:jogamp.newt.driver.bcm.vc.iv.WindowDriver, consumed false, when:1440416398012 d 0ms]], visible true 362/66, win[362/66 348x317], pixel[348x317] Window setSize: END 348x317, visibleAction 0 Window resized to width=348 height=317Window.positionChanged: (main-Display-.x11_:0.0-2-EDT-1): (defer: false) 362/66 -> 1/30 - windowHandle 0x1600002 parentWindowHandle 0x0 definePosition: 362/66 -> 1/30 consumeWindowEvent: WindowEvent[WINDOW_MOVED, NEWTEvent[source:jogamp.newt.driver.x11.WindowDriver, consumed false, when:1440416398013 d 0ms]], visible true 1/30, win[1/30 348x317], pixel[348x317] Window setPosition: 362/66 -> 1/30, fs false, windowHandle 0x67ca4418 reconfigureWindowImpl want 1 30 348 317 reconfigureWindowImpl rect 1 30 348 317 Window.positionChanged: (main-Display-.bcm.vc.iv_nil-1-EDT-1): (defer: false) 362/66 -> 1/30 - windowHandle 0x67ca4418 parentWindowHandle 0x0 definePosition: 362/66 -> 1/30
(In reply to comment #8) > (In reply to comment #3) > > > cc3: when you resize the x11 window then the overlay gets resized but get a > > new position (bug in bcm.vc.iv driver?) > > Captured a log using -Dnativewindow.debug=Window to see what happens during > resize > first X11(underlay) sends a WINDOW_RESIZED event and .bcm.vc.iv gets resized > correctly > then happens the unexpected: the X11(underlay) thinks it have moved to a new > position and sends a WINDOW_MOVED relative to top left corner + window > decorations, a bug in the NEWT X11 Window driver! > There was no bug in the NEWT X11 Window driver instead I was using the wrong semantics. Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1178 Bug 1178: Fix cc3: Set position using LocationOnScreen coordinates. https://github.com/xranby/jogl/commit/5db1ba769b6a4b8f8e7148728bb1a82149c822ee
(In reply to comment #9) > > Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1178 > > Bug 1178: Fix cc3: Set position using LocationOnScreen coordinates. > https://github.com/xranby/jogl/commit/5db1ba769b6a4b8f8e7148728bb1a82149c822ee Unfixed corner cases: cc1: if you minimize the X11 window the overlay is still visible Fix for cc1 requires that NEWT can send minimize events. cc2: if you move the X11 window outside the visible screen then the overlay gets recentered by bcm.vc.iv code to be inside the screen. Fix for cc2 require that the bcm.vc.iv driver send a new WindowEvent when it have re-centered inside the screen. cc5: re-use the x11 newt events as is then it would support multiple mousepointers etc cc6: if you render the bcm.vc.iv window transparent -> caps.setBackgroundOpaque(false); then you will see that the tracker window newer repaints -> looks a bit like a mess Fix for cc6 require that the X11UnderlayTracker NEWT windows gets repainted with a transparent color.
Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1178 Included a fix for keyboard input, it was misbehaving using all CAPS ;) https://github.com/xranby/jogl/commit/a963506dc19eca14f0fe7bbf22700b5791bd6821 Bug 1178: X11UnderlayTracker: Resend identical KeyCode, KeySymbol and KeyChar
Bug 1205: ee2fea13b20644e45c77f12a8b6d6f55941c27c8 have fixed cc6: when you render the bcm.vc.iv window transparent -> caps.setBackgroundOpaque(false); Then the underlay window is transparent as well. By using the default window manager then you will see that the tracker window repaints with a black colour this is expected because the default windowmanager on the pi do not use a compositor. Running remotely using ssh -X from a X11 machine using a compositor demonstrate that the Underlay window indeed is transparent! Unfixed corner cases: cc1: if you minimize the X11 window the overlay is still visible Fix for cc1 requires that NEWT can send minimize events. cc2: if you move the X11 window outside the visible screen then the overlay gets recentered by bcm.vc.iv code to be inside the screen. Fix for cc2 require that the bcm.vc.iv driver send a new WindowEvent when it have re-centered inside the screen. cc5: re-use the x11 newt events as is then it would support multiple mousepointers etc
New corner case cc11: NEWT getLocationOnScreen occasionally cause the NEWT EDT to deadlock. wget http://jogamp.org/deployment/archive/master/gluegen_886-joal_612-jogl_1431-jocl_1078/fat/jogamp-fat.jar java -cp jogamp-fat.jar com.jogamp.newt.opengl.GLWindow java.lang.RuntimeException: Waited 5000ms for: <3f1de3, 98e2b>[count 1, qsz 0, owner <main-Display-.bcm.vc.iv_nil-1-EDT-1>] - <main-Display-.x11_:1.0-2-EDT-1> at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198) at jogamp.newt.WindowImpl.getLocationOnScreen(WindowImpl.java:1134) at jogamp.newt.driver.x11.X11UnderlayTracker.windowMoved(X11UnderlayTracker.java:141) at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:4340) at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:4271) at jogamp.newt.WindowImpl.positionChanged(WindowImpl.java:4495) at jogamp.newt.WindowImpl.sizePosMaxInsetsChanged(WindowImpl.java:4659) at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method) at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:112) at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4403) at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4397) at jogamp.newt.WindowImpl.createNative(WindowImpl.java:751) at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:1222) at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1277) at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:133) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372) DefaultEDT.run(): Caught exception occured on thread main-Display-.x11_:1.0-2-EDT-1: RunnableTask[executed true, tTotal 6150 ms, tExec 6150 ms, tQueue 0 ms, attachment null, throwable java.lang.RuntimeException: Waited 5000ms for: <3f1de3, 98e2b>[count 1, qsz 0, owner <main-Display-.bcm.vc.iv_nil-1-EDT-1>] - <main-Display-.x11_:1.0-2-EDT-1>] java.lang.RuntimeException: Waited 5000ms for: <3f1de3, 98e2b>[count 1, qsz 0, owner <main-Display-.bcm.vc.iv_nil-1-EDT-1>] - <main-Display-.x11_:1.0-2-EDT-1> at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:198) at jogamp.newt.WindowImpl.getLocationOnScreen(WindowImpl.java:1134) at jogamp.newt.driver.x11.X11UnderlayTracker.windowMoved(X11UnderlayTracker.java:141) at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:4340) at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:4271) at jogamp.newt.WindowImpl.positionChanged(WindowImpl.java:4495) at jogamp.newt.WindowImpl.sizePosMaxInsetsChanged(WindowImpl.java:4659) at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method) at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:112) at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4403) at jogamp.newt.WindowImpl.waitForVisible(WindowImpl.java:4397) at jogamp.newt.WindowImpl.createNative(WindowImpl.java:751) at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:1222) at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1277) at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:133) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372)
(In reply to Xerxes Rånby from comment #13) > New corner case > cc11: NEWT getLocationOnScreen occasionally cause the NEWT EDT to deadlock. > > wget > http://jogamp.org/deployment/archive/master/gluegen_886-joal_612-jogl_1431- > jocl_1078/fat/jogamp-fat.jar > java -cp jogamp-fat.jar com.jogamp.newt.opengl.GLWindow > > java.lang.RuntimeException: Waited 5000ms for: <3f1de3, 98e2b>[count 1, qsz > 0, owner <main-Display-.bcm.vc.iv_nil-1-EDT-1>] - > <main-Display-.x11_:1.0-2-EDT-1> Have have stopped seeing this NEWT EDT deadlock after i have improved the power supply to my raspberry pi. If the power supply is inadequate then the GPU may brownout causing a GPU stall that in turn trigger a NEWT EDT deadlock. The Raspberry Pi have an early brownout detection visualized as a "rainbow" square rendered into the upper right corner of the screen. If you see this "rainbow" square be cautious and fix your power supply! The Pi will throttle the GPU and CPU in order to save itself however a GPU stall is likely to happen.