Lines Matching refs:t
39 You don't need detailed knowledge of the app framework, and very few API calls
40 will be mentioned, but the material herein doesn't overlap much with other
266 other facts you probably won't care about ("handle" and "hints" and "flags" and
271 shown above are using overlays, FB_TARGET isn’t being used for this frame. The
296 with an overlay, so we can't alter the buffer contents until the display is done
299 scanning the layer list, looking for updates. SurfaceFlinger won't find any new
348 bars, which for our purposes here aren’t changing, so SurfaceFlinger keeps using
354 <p><strong>**</strong> - The buffer doesn’t actually “empty”; if you submit it
361 zero CPU and GPU time. But we can't count on that, so we need to allow a little
483 buffer appropriately. To ensure that a buffer isn't updated by two clients at
501 to a Surface, but the Canvas-based "CPU renderer" cannot. This means you can't
582 independent concept. You can draw on an EGLSurface that isn't backed by a
608 View. Most of the details don't matter for this discussion, but it's helpful to
625 doesn't happen synchronously, which is why you should provide a callback that
634 can't totally ignore the UI thread -- you still have to coordinate with the
707 handles the scaling. If you don't want to letter- or pillar-box your game, you
722 Most apps won't need to know anything about EGL to use GLES with GLSurfaceView.</p>
725 easier. In some situations, it can get in the way. Use it if it helps, don't
726 if it doesn't.</p>
743 configure your renderer a bit differently, and there are things you can't do
868 BufferQueue, and it will stall until one is available. There won't be any
925 doesn't have to do anything -- composition and display will either be handled by
937 can't change the Surface that a MediaCodec decoder uses without fully
958 <p>Implementing this activity with SurfaceView would be a bit harder. We can't
1021 between buffer swaps, your animation won't update at a consistent rate. When
1023 probably won't notice the bumps.</p>
1026 because the BufferQueue isn't full yet. The computed time between frames will
1030 isn't noticeable. A game that pauses animation occasionally and then returns to
1036 actual VSYNC time is passed in as an argument. So even if your app doesn't wake
1063 your eyes are very good, though, you won't see the animation stutter. At 60fps,
1094 sleep() isn't perfectly consistent, and moveBlock() takes a nonzero amount of
1159 will already exist and sometimes it won't (e.g. it's still alive after toggling
1161 created before we do some initialization in the thread, but we can't simply do
1162 it in the <code>surfaceCreated()</code> callback because that won't fire again
1163 if the Surface didn't get recreated. So we need to query or cache the Surface
1199 you've used systrace before, you've probably seen them, but maybe weren't sure