Other techniques and troubleshooting

Most of the techniques described in this chapter can be tried from the start of your project, then reviewed and revised as you increase your understanding of your system.

Many of these techniques are for optimizing your application. If you have implemented them and you still find that your splash screen application isn't showing your content on the display in an optimal time, try to find other areas to optimize in your system. These can include:

• Determine if your splash screen application has inadvertently used composition (created a framebuffer) when rendering an image to a display. Because there's time required to set up the framebuffer, in general, the use of framebuffer increases the time it takes to show content on the display.

  To determine if a framebuffer was created, run your splash screen application, and immediately after it completes, check if there are window entries under the following folder:

  /dev/screen/0

  If there are any entries, you should investigate to find out what is causing the framebuffer to be created.

• If your hardware supports hardware pipelines and you require multiple, visible windows, consider using the hardware pipelines to do the composition rather than creating a framebuffer. This technique can help to show content on the display more quickly. For more information about using pipelines, see the Composition section in the Displaying the contents of windows chapter of the Screen Developer's Guide.
• Use tools such as tracelogger to trace events and to get measurements on your system. You can use the measurements to help identify latencies in your startup time, and areas that you should consider optimizing.
• Use slog2info and screeninfo to help debug your splash screen application. For more information about debugging your application, see the Debugging chapter in the Screen Developer's Guide.

• If you have a multicore hardware platform, separate the decoding of an image and the image rendering operations into separate threads. If you run the threads on separate cores, you can decode and render images in parallel.

  With this technique you can show your content before you even start the Screen service; that is, before you make a call to one of the screen_attach_*_buffer() functions to write the buffer (see screen_attach_pixmap_buffer(), screen_attach_stream_buffers(), and screen_attach_window_buffers in the Screen Library Reference chapter of the Screen Developer's Guide).

  In short, you will be able to show your initial content before doing all the work that is needed to get the Screen service started.

For more suggestions to troubleshoot your application and techniques to trace through your code, see the Debugging chapter in the Screen Developer's Guide.