QNX Software Development Platform SP1. Optimizing Startup Times

Transcription

1 QNX Software Development Platform SP1 Optimizing Startup Times for the QNX Screen Graphics Subsystem

2 , QNX Software Systems Limited, a subsidiary of BlackBerry Limited. All rights reserved. QNX Software Systems Limited 1001 Farrar Road Ottawa, Ontario K2K 0B3 Canada Voice: Fax: info@qnx.com Web: QNX, QNX CAR, Momentics, Neutrino, and Aviage are trademarks of BlackBerry Limited, which are registered and/or used in certain jurisdictions, and used under license by QNX Software Systems Limited. All other trademarks belong to their respective owners. Electronic edition published: January 20, 2016

3 Optimizing Startup Times Contents About This Guide...5 Typographical conventions...7 Technical support...9 Chapter 1: Optimizing Screen Startup Time...11 Chapter 2: Configure a Primary and Secondary IFS on the System...17 Example for the Freescale i.mx6 SABRE Smart board...20 Chapter 3: Optimize the Screen Configuration File...23 Chapter 4: Optimize the Boot Script to Start Screen and the Splash Screen Application Earlier...25 Sample script section in the buildfile for an i.mx6 SABRE Smart board...27 Chapter 5: Optimize the Splash Screen Application...29 Choose how to render to a display...32 Avoid using a framebuffer...33 Optimizing the usage of APIs...34 Optimize the usage of windows from Screen...35 Use multiple threads...36 Use statically linked libraries...37 Chapter 6: Other Techniques and Troubleshooting...39 Appendix A: Other System Optimization Practices...41 About the system startup sequence...42 Optimize the bootloader...44 Use the optimized image scan functions...45 Generic techniques to reduce the size of the IFS...46 Reduce the size of the startup program...48 Remove unnecessary debug printing...49 Enable fast reading in the SD card...50 Use compression strategies...51 Reorder the startup program...52 Make careful use of the default boot script...53 Consider the placement of waitfor statements...54 Index...57

4 Contents

5 About This Guide Optimizing Startup Times describes strategies and techniques that you can use to reduce the time it takes for your system to boot and show content (graphics or video) on a display. Because the time to boot is dependent upon the design and implementation of your system, this guide describes general techniques instead of concrete steps to optimize your system. In this document, we refer to: content, as a static image or a video splash screen application (or splash screen_application in the examples) as the program, which you create to show graphic or video on the display It's important to note that the actual time saved (typically in the order of milliseconds) varies between hardware platforms. As the system architect or developer, you should implement the optimization techniques that meet the requirements for your system. Some hardware platforms aren't functional until all the necessary device drivers are started. For those platforms, you won't be able to take advantage of all the techniques described in this guide to optimize the startup time. Some of the techniques described in this guide are targeted for hardware platforms that permit you to start device drives as required, rather than requiring that all device drivers are started before any applications can run. We recommend that you review the following guides to have a good understanding of how to design an embedded system to boot quickly and work with multiple images (such as creating a primary and secondary IFS): Building Embedded Systems Guide Reloadable Image Filesystems chapter in the QNX Neutrino Technotes Making Multiple Images chapter in the QNX Neutrino Technotes Here's what's contained in this guide: For information on: An overview of the areas you can optimize to show content on the display as quickly as possible. In addition, an overview of the Screen optimization strategy is provided A summary of the techniques to split the IFS into a primary and secondary IFS A summary of the techniques to optimize the Screen configuration file A summary of techniques to optimize your boot script A summary of techniques and strategies to optimize the implementation of your splash screen application Go to: Optimizing Screen Startup Time Configure a Primary and Secondary IFS on the System Optimize the Screen Configuration File Optimize the Boot Script to Start Screen and the Splash Screen Application Earlier Optimize the Splash Screen Application 2015, QNX Software Systems Limited 5

6 About This Guide For information on: A summary of techniques you can use to optimize the boot time of an embedded system Go to: Other System Optimization Practices , QNX Software Systems Limited

7 About This Guide Typographical conventions Throughout this manual, we use certain typographical conventions to distinguish technical terms. In general, the conventions we use conform to those found in IEEE POSIX publications. The following table summarizes our conventions: Reference Code examples Command options Commands Environment variables File and pathnames Function names Keyboard chords Keyboard input Keyboard keys Program output Variable names Parameters User-interface components Window title Example if( stream == NULL ) -lr make PATH /dev/null exit() Ctrl Alt Delete Username Enter login: stdin parm1 Navigator Options We use an arrow in directions for accessing menu items, like this: You'll find the Other... menu item under Perspective Show View. We use notes, cautions, and warnings to highlight important messages: Notes point out something important or useful. CAUTION: Cautions tell you about commands or procedures that may have unwanted or undesirable side effects. WARNING: Warnings tell you about commands or procedures that could be dangerous to your files, your hardware, or even yourself. 2015, QNX Software Systems Limited 7

8 About This Guide Note to Windows users In our documentation, we use a forward slash (/) as a delimiter in all pathnames, including those pointing to Windows files. We also generally follow POSIX/UNIX filesystem conventions , QNX Software Systems Limited

9 About This Guide Technical support Technical assistance is available for all supported QNX products. To obtain technical support for any QNX product, visit the Support area on our website ( You'll find a wide range of support options, including community forums. 2015, QNX Software Systems Limited 9

10

11 Chapter 1 Optimizing Screen Startup Time When your system first powers up, you might want to provide a visual cue to indicate that the system is coming up or is in the process of coming up. For this scenario, you'll probably want to show content on the display as quickly as possible (i.e., with no or little delay). For example, you might want to show a graphic (splash screen) or even a video feed from a camera as the other components of your system initialize and start. This guide describes several techniques that you can use to reduce the time it takes for content to show on the display. It's important to mention that the more time it takes to boot your base system, the more time that it takes to show content on a display. For that reason, you must consider how to optimize the boot time for your base system (IPL, kernel, Core OS). Though it isn't the primary purpose of this document to discuss these generic system optimization techniques, we have summarized common techniques in the Other System Optimization Practices appendix. After your system boots, a boot script runs to start device drivers, start services, and run applications. In the boot script, you should start Screen and run a splash screen application (an application that shows a graphic or video on the display) as soon as possible. After the boot script finishes, control is usually passed to a main system application, such as an HMI (human machine interface). For more details about the system startup sequence, see About the System Startup Sequence section in the Other System Optimization Practices appendix. 2015, QNX Software Systems Limited 11

12 Optimizing Screen Startup Time Areas in the bootup sequence where time can be optimized There are a few areas that you can optimize on your system to quickly show content on the display. It's a good idea to have a good understanding of the boot optimization strategy for Screen before you dive in to the techniques. In general, Screen is optimized to start quickly on a system. T0 T1 T2 T3 T4 T5 Primary IFS Secondary IFS 1 Screen Load Screen-related files and start Screen Service Display Drivers (WFD) Splash screen application Binaries Resources Mount libraries, GPU drivers and other files required for other applications Power on Screen binaries Screen configuration 2 4 Base System (Kernel,Core OS) 3 Boot script Time T0 T1 T2 T3 T4 T5 PLL, IPL, and Startup Main System applications run (e.g.hmi) Figure 1: Areas that can be optimized to improve the time to show content on display. Here are the areas where you can look to optimize the time it takes to show content on a display: It's important to mention that this process of going through the following areas isn't linear, but best done in an iterative manner. For example, you might be able to further optimize your configuration file after you optimize your splash screen application. 1. Configure your system to have a primary and a secondary IFS (image filesystem) To help you display content quickly, we recommend that you make the IFS as small as possible. If you have many files that need to be loaded into RAM, split the IFS into a primary and a secondary IFS. The primary IFS should have only the minimum files and libraries required to boot the system and show content on the display. It's important to remember that you require a secondary IFS only if files need to be loaded into memory; otherwise, you can put the files into the filesystem. For more information about creating a primary and secondary IFS, see the Configure a Primary and Secondary IFS on the System chapter. 2. Optimize the Screen configuration file To potentially reduce the time it takes for the Screen service to come up, you should remove any unnecessary parts from the graphics.conf file. For more information, see the Optimize the Screen Configuration File chapter , QNX Software Systems Limited

13 Optimizing Screen Startup Time 3. Optimize your boot script to start Screen early In your boot script (which is generated and configured in the script section of the buildfile that comes with your hardware platform's board support package (BSP)), run the minimal services, start Screen, and then run your splash screen application. You might also need to load any libraries your splash screen depends on or start device drivers required for your content to show. For more information, see the Optimize the Boot Script to Start Screen and the Splash Screen Application Earlier chapter. 4. Optimize the splash screen application Most of the optimizations occur in the implementation of your splash screen application. You should try to use software rendering instead of hardware rendering. Much of the time that you can save can directly be attributed to what resources and features your splash screen application demands from Screen. For example: You can reduce the libraries that Screen dynamically loads if you use Screen's software rendering to show an image. You can load an image in memory rather than read an image from file. For more information, see the Optimize the Splash Screen Application chapter. After the boot script runs, generally control is handed off to a main system application (e.g., HMI). If you run other applications that also use Screen, for optimal performance, we recommend that you use the same techniques to optimize all applications as described in the Optimize the Splash Screen Application chapter. Screen boot optimization strategy By default, Screen is optimized to start quickly and use as few system resources as possible. Screen loads resources and starts device drivers only when necessary. As a result of this, the timing for subsequent calls that require the same device driver is shorter than the first because the device driver is already running. For this reason, it's important that you consider how to implement your splash screen application. Your implementation will often use at least the display driver, but if your splash screen application requires more device drivers to start, it will increase the time required for your content to show on a display. For example, if your splash screen application uses OpenGL ES hardware rendering (not recommended), additional device drivers are started, which increases the time for content to show on the display. There are several ways which you can implement your system to help show content faster on the display. In the following diagram, the green oval on the right lists the important boot optimization techniques that decrease the time to show content on the display. Listed in the red oval on the left, are the non-recommended techniques (which you might need to use due to system requirements) that typically increase the time it takes to show content on the display. For example, the use of framebuffers or starting Screen late in your system, can significantly increase the time it takes to show content on the 2015, QNX Software Systems Limited 13

14 Optimizing Screen Startup Time display. Conversely, not using framebuffers and starting Screen early in the boot process can significantly reduce the time it takes to show content on the display. More time show content on the display Less time to show content on the display use of framebuffers no use of framebuffers SLOWER larger IFS use single thread in app non-optimized bootscript larger graphics.conf file use dynamically linked libraries use multiple threads in app optimized bootscript smaller graphics.conf file use statically linked libraries smaller IFS FASTER use GPU-or blitter-based rendering use software rendering/static images start Screen late in boot process start Screen early in boot process read image from file in splash screen application image embedded in splash screen application Figure 2: Impact of boot optimization techniques The previous diagram also shows how some techniques can have a larger impact than others to decrease or increase the time it takes to show content on the display. For example, if you start Screen early in the boot process or remove the need to use framebuffers in your application, those techniques are more effective for reducing the time to takes to show content on the display as compared to techniques, such as a reducing the size of the graphics.conf file or using statically linked libraries. If you had to choose a technique to focus on, choose the ones that are suitable for your system and applications, while giving the greatest benefit. Hardware considerations when working with Screen There are several hardware considerations when you design any system. The following are hardware considerations that specifically can increase the time it takes to show content on the display when using Screen: For input devices, such as a mouse, don't enable the mouse cursor because it causes a framebuffer to be created, which increases the time it takes to show content on the display. If your system requires any input (other than touch input), you should start the hid device drivers. With respect to touch input, we recommend that you start the mtouch driver after your splash screen application runs. For example, if your system uses a mouse as input, you should start the hid driver before the Screen service, but don't show the mouse cursor. If your display or monitor is connected to your hardware via an output cable, such as an HDMI cable, the device driver might have a longer detection phase than you expect, which increases the , QNX Software Systems Limited

15 Optimizing Screen Startup Time time it takes to show content on a display. For that reason, it's better to use an attached device or a device driver that doesn't have a detection phase. 2015, QNX Software Systems Limited 15

16

17 Chapter 2 Configure a Primary and Secondary IFS on the System To show content on the display as soon as possible, we recommend that you include only the necessary files (libraries, configuration files, device drivers, binaries, etc.) in the primary IFS for the splash screen application to run. In general, the fewer components that you have in your IFS, the faster your system should boot. Files that aren't required for the splash screen application to run, but that must be loaded into RAM memory should be put into the secondary IFS. If the files aren't required in an IFS, consider putting the files in a filesystem that's mounted by the primary IFS. For more information about creating an IFS, see the Making an OS Image chapter in Building Embedded Systems and the mkifs chapter in the Neutrino RTOS Utilities Reference. Since the kernel, Screen service, and your splash screen application won't run until the IPL (initial program loader) copies the primary IFS from flash memory into RAM, the smaller you make the IFS, the faster the copy operation is, and the sooner those components can begin to run. For more information about the IPL, see the About the system startup sequence section in the Other System Optimization Practices appendix. T0 T1 T2 T3 T4 T5 Primary IFS Secondary IFS 1 Screen Load Screen-related files and start Screen Service Display Drivers (WFD) Splash screen application Binaries Resources Mount libraries, GPU drivers and other files required for other applications Power on Screen binaries Screen configuration 2 4 Base System (Kernel,Core OS) 3 Boot script Time T0 T1 T2 T3 T4 T5 PLL, IPL, and Startup Main System applications run (e.g.hmi) Figure 3: Configure a primary and secondary IFS on the system. Here's a general guideline of what to put into the primary IFS and secondary IFS to optimize the boot time: Primary IFS: Include the kernel, Screen service, and the splash screen application, configuration files, and any other components that must be available before the content needs to show on the 2015, QNX Software Systems Limited 17

18 Configure a Primary and Secondary IFS on the System display (i.e., procnto, display drivers, etc.). For example, if your system requires networking or video from a camera, you'll need to include those binary files in your primary IFS. For general guidelines of what to include in the primary IFS, see Minimum files to load to run Screen later in this chapter. To keep the size of the primary IFS small, you should optimize your splash screen application to use as few libraries, resources, and device drivers as possible. Since the required libraries are specific to how optimized your splash screen application is, see the Optimize the Splash Screen Application chapter for more optimization techniques. The binaries required for Screen are listed in the sample buildfile of the Board Support Package (BSP). To find the BSP for your board, see BSPs (board support packages) Secondary IFS: Include the files (libraries, configuration files, other applications) for the components that run after the splash screen application. For example, if you require networking for your system, but networking isn't required before the content shows on the display, put the required files into a secondary IFS. For information about Screen-related libraries that can be candidates to load in the secondary IFS, see the Board-specific Screen libraries that be loaded later section later in this chapter. Minimum files to load and to run Screen and a splash screen application Though the time saved varies between hardware platforms and system requirements, we have provided a guideline for the minimum set of files to include in your primary IFS to show content on a display. It's not possible to indicate the exact names of the required files because the file names vary between hardware platforms. For example, the memory allocator file is based on a value in the graphics.conf file. These are the suggested minimum set of files to include in the primary IFS to run a splash screen application, excluding any dependencies: the Screen resource manager binary (screen) the Screen API (libscreen) the graphics buffer manager used by Screen (libgmem.so) the Screen configuration file (graphics.conf) the memory buffer allocator for the hardware board (screen- <hardware_platform_name>.so where hardware_platform_name is name specified in the alloc-config property in the graphics.conf. For information about the file name, see the Determine the name of the board-specific memory buffer file section later in this chapter. the display driver library (libwfd.so) the minimum board-specific libraries and display drivers. To understand how to determine the files to include, see the Determine the board-specific libraries to include section later in this chapter. If you have any custom drivers for your board, you should also include them in the primary IFS. the splash screen application binaries and any related files and libraries that the application uses. For example, if you want to show content from a PNG image file, in addition to binaries for the splash screen application, you should include: , QNX Software Systems Limited

19 Configure a Primary and Secondary IFS on the System the codecs files for the image file (e.g., img_codec_png.so, libimg.so) the image file (e.g., splash_screen_application.png file) any other configuration files required for your splash screen application (e.g., splash_screen_application.conf) You could statically link the libraries required for your splash screen application to reduce the number of libraries to load into the IFS. You can run the objdump_variant (e.g., ntoarm-objdump or ntox86-objdump) utility on your host to determine any dependencies that the above list of files have. For more information, see objdump in the Neutrino RTOS Utilities Reference guide. For example, you can use this command to determine the list of dependencies: objdump -x grep NEEDED Alternatively, you can set the environment variable LD_DEBUG=lib to show the Screen dependencies. For some libraries, you can choose to statically link them with your splash screen application. For example, you could statically link the PNG library required to decode your splash screen image. For more information on this technique, see Use statically linked libraries section in the Optimize the Splash Screen Application chapter. Determine the board-specific libraries to include To determine the libraries that are required for each hardware board, refer to your default graphics.conf file: EGL The files that are candidates to be loaded later (i.e., not necessary required in the primary IFS, depending on your system requirements). WFD The display device drivers that Screen requires. Determine the name of the board-specific memory buffer file To determine the name of this file, find the alloc-config property in winmgr section of the graphics.conf file and use this algorithm: "screen-" + < value of alloc-config > + ".so" 2015, QNX Software Systems Limited 19

20 Configure a Primary and Secondary IFS on the System Example for the Freescale i.mx6 SABRE Smart board Say that you have a splash screen application that runs on a Freescale i.mx6 SABRE Smart board and the splash screen application is called splash screen_application. The splash screen application shows a PNG file. Here's how you determine the board-specific files that must be included in the primary IFS in the provided graphics.conf file for the Freescale i.mx6 SABRE Smart board: WFD section EGL section Figure 4: Sample graphics.conf file for i.mx6 SABRE Smart board. Board-specific memory allocator filename To determine the filename of the memory allocator, see the alloc-config entry in the graphics.config as follows:... alloc-config = imx6xbuf... Therefore, the name of the memory allocator file is screen-imx6xbuf.so because the value is prefixed with screen- and suffixed with.so. Board-specific Screen libraries that must be loaded in the primary IFS The display driver files determined from the previous example graphics.conf file are as follows: libwfdcfg-imx6x-hdmi.so libimx6xcscgamma-generic.so libwfdimx6x.so , QNX Software Systems Limited

21 Configure a Primary and Secondary IFS on the System Summary of minimum files required for Screen The following table summarizes the minimum files required to show content on the display: File graphics.conf csc_gamma.conf libwfdcfg-imx6x-hdmi.so libimx6xcscgamma-generic.so libwfdimx6x.so libgmem.so libwfd.so screen-imx6xbuf.so libscreen.so Purpose The Screen service configuration file Configuration file for CSC gamma The HDMI device driver Generic board CSC Gamma library Generic board WFD library Memory Manager for Screen Driver for WFD The library to allocate buffers The Screen library Summary of splash screen application files Since the splash screen application shows a PNG image (static image), these are the application-specific libraries for our example: File splash_screen_application img_codec_png.so libimg.so img.conf splash screen_application.png Purpose Your splash screen application, which you create The codec required to show an image The Image library to render an image The configuration file to configure the codec for the Image library The static graphic (content) to show on the display Board-specific Screen libraries that can be loaded later The candidate files that can be loaded in the secondary IFS or a filesystem are listed in the EGL section of the graphics.conf file for your board. To improve the startup time for Screen, we recommend that you put these files in the secondary IFS if you need them loaded into memory. If you put any of the files in your primary IFS, you will risk increasing the startup time of your system because it can significantly increase the size of the primary IFS. For example, if your system applications use OpenGL ES hardware rendering, blitting, etc., but your splash screen application doesn't, you can put the OpenGL ES libraries in the secondary IFS. From the previous sample graphics.conf file for the i.mx6 SABRE Smart board, these are the files that you could include in your secondary IFS: libgal.so libegl_viv.so 2015, QNX Software Systems Limited 21

22 Configure a Primary and Secondary IFS on the System libvsc.so libgles_cm_viv.so libglesv2_viv.so libopenvg_viv.so libglslc.so libgalcore.so , QNX Software Systems Limited

23 Chapter 3 Optimize the Screen Configuration File The graphics.conf file is a Screen configuration file that you can optimize to help reduce the time it takes for the Screen service to start. A default version of the graphics.conf is provided in the BSP kit for your hardware platform. T0 T1 T2 T3 T4 T5 Primary IFS Secondary IFS 1 Screen Load Screen-related files and start Screen Service Display Drivers (WFD) Splash screen application Binaries Resources Mount libraries, GPU drivers and other files required for other applications Power on Screen binaries Screen configuration 2 4 Base System (Kernel,Core OS) 3 Boot script Time T0 T1 T2 T3 T4 T5 PLL, IPL, and Startup Main System applications run (e.g.hmi) Figure 5: Optimize the graphics.conf file. Here's how you can modify the graphics.conf file to optimize the startup time for Screen: Reduce what's in the graphics.conf file. You should remove any options that aren't required for your system. For more information, see the Optimize the contents of the graphics.conf file section later in this chapter. Specify the pixel format in the graphics.conf file. For more information about modifying these settings, see the Configure display options chapter. For more information about modifying the graphics.conf, see the Configure Screen chapter in the Screen Developer's Guide. Optimize the contents of the graphics.conf file As part of the Screen initialization process, everything in the graphics.conf file is read and parsed. These are some recommended approaches to help you reduce the size of the graphics.conf : Put files that the graphics.conf refers to in the primary IFS if they are required to show content on the display. Your graphics.conf can still refer to files that aren't in the primary IFS, but loaded in 2015, QNX Software Systems Limited 23

24 Optimize the Screen Configuration File the secondary IFS or filesystem. This is also an important consideration to help you to reduce the size of the primary IFS. Remove all comments and unnecessary options from the graphics.conf file to make it as small (or short) as possible. This helps to improve the startup time for the Screen service because there isn't as much to process. The graphics.conf file can be found at these locations: your host machine at $QNX_TARGET/ cpu/usr/lib/graphics/ platform/ your target at /usr/lib/graphics/platform/ where platform is the name of the hardware platform (e.g., imx6x) Configure display options Screen is designed to be flexible and fault-tolerant. For this reason, by default, Screen scans the hardware to determine the best settings for the display, which requires extra time. When possible, configure the pixel format in the graphics.conf file to skip the scanning process and save time provided you know the correct settings on the display or monitor. To configure the pixel format, modify the following option in the display section of the graphics.conf file: formats All the pixel formats that will be returned as supported to applications. If this display option isn't specified, Screen must take the time to determine which pixel formats are supported by your display hardware. You can save time if you can avoid this discovery stage. For more information about see about the display parameters, see the Configure display subsection in the Configuring Screen chapter of the Screen Developer's Guide , QNX Software Systems Limited

25 Chapter 4 Optimize the Boot Script to Start Screen and the Splash Screen Application Earlier With the QNX Neutrino RTOS and its microkernel architecture, you can modify the script section in the buildfile to start services or applications earlier to take advantage of any idle time on the CPU. This flexibility allows you to optimize the time for certain components in your system to come up earlier. The script section is used to generate the boot script for a system. T0 T1 T2 T3 T4 T5 Primary IFS Secondary IFS 1 Screen Load Screen-related files and start Screen Service Display Drivers (WFD) Splash screen application Binaries Resources Mount libraries, GPU drivers and other files required for other applications Power on Screen binaries Screen configuration 2 4 Base System (Kernel,Core OS) 3 Boot script Time T0 T1 T2 T3 T4 T5 PLL, IPL, and Startup Main System applications run (e.g.hmi) Figure 6: Optimize the script section in the buildfile. You can start applications before starting some device drivers if it's sensible for your system and the hardware platform permits you to start device drivers as required. For example, if your system requires network connectivity, you would need to start a network driver, but because the splash screen application doesn't require network connectivity, you could, in fact launch your splash screen application before you start the network driver. This way, the system can show the content on the display more quickly because it won't need to wait for the network driver to start. CAUTION: This technique requires that you have a good understanding of the configuration of your buildfile. If any file is missing in the configuration, your system may fail to boot. 2015, QNX Software Systems Limited 25

26 Optimize the Boot Script to Start Screen and the Splash Screen Application Earlier Some hardware platforms require that all devices drivers be started at one time. For those platforms, you might not be able to use this technique to start applications before some of the device drivers. Typically, the default boot script that comes with your BSP (see the BSPs (board support packages on Foundry27)) have Screen configured to start as one of the last services. We recommend that you start the following services in this order as soon as you can to show an image on the display quickly: 1. The Screen service (screen) Don't use the an "&" (ampersand) to start screen in the background because the Screen service automatically puts itself into background when it starts. If you specify the "&", a waitfor may be executed, which may increase the time it takes to show content on the display. For more information, see Consider the placement of waitfor statements in the Other System Optimization Practices appendix. 2. The splash screen application In some situations, you might want to start some services, such as slogger early so that you can debug your system. This practice is useful in the early stages of the development process, but later you might choose to disable slogger after your system is ready for production. You might find it useful to keep services, such as slogger, enabled because it can help customer support troubleshoot issues in production. In some situations, you might have a requirement where applications that use hardware rendering (OpenGL ES, OpenVG, blitting, etc.) need to come up quickly. In this case, you can choose to start the hardware-rendering application at the same time as the splash screen application. Running the applications in parallel won t increase the time it takes to show content on the display, despite the fact that the hardware rendering application may cause device drivers to start, unless there s CPU or disk contention. However, if during the startup sequence or the transition from one application to another application, a framebuffer gets created, there s potential for the following to occur on the splash screen application: if the content has been shown, animation (such as a video feed) you might experience momentary pausing or stutter if the content hasn't been shown, the time to show the content may increase , QNX Software Systems Limited

27 Optimize the Boot Script to Start Screen and the Splash Screen Application Earlier Sample script section in the buildfile for an i.mx6 SABRE Smart board Here's an example of the minimum list of libraries specified in the script section of the buildfile, which is used to generate a boot script:... <boot script portion>... [+script].script = { # Initialize the console procmgr_symlink../../proc/boot/libc.so.3 /usr/lib/ldqnx.so.2 TZ=EDT5EST... <Other libraries required for your system to start>... ########################################################################### ## Start slogger, consider removing from production loads if necessary ########################################################################### pipe & slogger &... ########################################################################### ## Graphics support - Screen ########################################################################### libwfd.so.1 /usr/lib/graphics/imx6x/libwfdimx6x.so=graphics/imx6x/libwfdimx6x.so /usr/lib/graphics/imx6x/libimx6xcscgamma-generic.so=graphics/imx6x/libimx6xcscgamma-generic.so [search=../install/armle-v7/usr/lib/graphics/imx6x] /usr/lib/graphics/imx6x/graphics.conf=graphics.conf /usr/lib/graphics/imx6x/scaling.conf=scaling.conf libscreen.so.1 libimg.so.1 img_codec_png.so.1 ########################################################################### ## Set environment and start the main shell ########################################################################### [perms=0744].console.sh={ echo setting env variables. export SYSNAME=nto export TERM=qansi export HOME=/ export PATH=:/bin:/usr/bin:/sbin:/usr/sbin:/proc/boot export LD_LIBRARY_PATH=:/lib:/usr/lib:/lib/dll:/proc/boot ####################################################################### ## Start the screen graphics ####################################################################### # echo Starting Screen Graphics... screen -c /usr/lib/graphics/imx6x/graphics.conf echo done. # Start your splash screen application to show content on the display # This application is code that you write splash_screen_application }... <Rest of buildfile> , QNX Software Systems Limited 27

28

29 Chapter 5 Optimize the Splash Screen Application To display your content as quickly as possible, you can optimize your splash screen application, which is the program that shows the content on the display. Based on your system requirements, the content you show can be a graphic (e.g., your company's logo) or even video (e.g., a live feed from a camera). If you implement your application to use more features and capabilities for rendering your content, the more demands you may put on Screen and the system resources. Screen on its own is loaded quickly, but an implementation can use features that cause Screen to start drivers or create a framebuffer, which increases the time to show the content on the display. T0 T1 T2 T3 T4 T5 Primary IFS Secondary IFS 1 Screen Load Screen-related files and start Screen Service Display Drivers (WFD) Splash screen application Binaries Resources Mount libraries, GPU drivers and other files required for other applications Power on Screen binaries Screen configuration 2 4 Base System (Kernel,Core OS) 3 Boot script Time T0 T1 T2 T3 T4 T5 PLL, IPL, and Startup Main System applications run (e.g.hmi) Figure 7: Optimize the splash screen application. Here are some techniques to consider when you implement your splash screen application: Optimize content There are several ways to optimize the content you show on the display. There are always trade-offs between the compression used for the image, the file size of the image, the quality of the image, as well as CPU time to process the image. Here are some techniques you can use: When possible, include the image as part of the splash screen application binary so that it's directly read into memory. Reading an image from file instead of memory is an additional operation you can avoid to save time. Reading an image from memory also means that you don't have to include libimg.so in the primary IFS to read an image. Instead, you need to statically link only the codec in your binary to decode the image. 2015, QNX Software Systems Limited 29

30 Optimize the Splash Screen Application Use RLE compression for image files that have multiple repeating areas in them. RLE-compressed files use less CPU, but sometimes have larger file sizes. If your content must be read from a file, ensure that the file size is optimized. The larger the file, the more likely it can increase the size of your primary IFS. Another consideration is when you show an image or video, the codecs must be included in the primary IFS. Choose an image format that uses a smaller codec. Ultimately, a larger primary IFS increases the time it takes for your system to be loaded. For more information about optimizing the primary IFS, see the Configure a Primary and Secondary IFS on the System chapter in this guide. Prevent Screen from starting additional drivers Depending on what your splash screen applications does, it may cause Screen to start device drivers, which can increase the time it takes to show content on the display. Here are some techniques to prevent device drivers from starting: Use software rendering for your application. In other words, avoid the use of hardware rendering, such as OpenGL ES, which requires that Screen start additional drivers. For more information about the types of rendering you can use, see Choose how to render to a display, below, and the Rendering chapter in the Screen Developer's Guide. You use SCREEN_PROPERTY_USAGE in your splash screen application to specify the intended use of the buffers, however, the device driver is started by Screen only when an API that required it is called. For that reason, to improve the time it takes for content to show on the display, we suggest that you avoid or delay API calls later in your application until content is show on the display. For more information about the settings that cause additional drivers to start, see the Optimizing the usage of APIs section later in this chapter. Prevent the creation of framebuffers In general, avoid creating framebuffers: Optimize the usage of windows in your application to use as few Screen features as possible. For more information, see the Optimize the usage of windows from Screen section later in this chapter. Use images that are the same size as the display to avoid scaling and use window buffers sizes that match the resolution of the display. For more information, see the Avoid using a framebuffer section later in this chapter.. Application implementation Here are some general techniques to help your application run more quickly: Use a single thread in your splash screen application to show the content. Use multiple threads when you have to start additional device drivers and when you have a multicore system, which permits you to perform operations in parallel. For example, you could decode an image and render the image in parallel. For more information about using multiple threads, see the Use multiple threads section later in this chapter.. For more information about developing multicore systems, see the Multicore Processing User's Guide , QNX Software Systems Limited

31 Optimize the Splash Screen Application If your application uses specific libraries or files for processing or showing an image, use statically linked libraries when possible. For example, you can statically link the libraries required to decode your image; that way, you don't need to include it in the primary IFS. For more information, see the Use statically linked libraries section later in this guide. It's important to remember the techniques that you use often have trade-offs in terms of time savings or impacts to your overall system. It's your responsibility to characterize and determine the best techniques for your system. For example, you can use PNG images for your splash screen, but the trade-off is that you must load a codec. If you decide to use RLE compression for your images, you might save on CPU processing time at the expense of increasing the primary IFS size. 2015, QNX Software Systems Limited 31

32 Optimize the Splash Screen Application Choose how to render to a display The way you choose to render the content to a display can affect how quickly the content is rendered the reason being that some types of rendering must load more resources and start additional device drivers. Here are the rendering options you can use for your application: Software rendering For Screen, the fastest way to display content is to use software rendering. No additional drivers need to start because you simply write the content to memory. Video capture If you're using video capture, you can't show anything faster than the time it takes to capture the video. However, after the video frames come in, say from a camera, you can immediately show the video feed on the display. The setup time depends on your hardware, but in general, it still takes less time to set up video capture than it does to load and start device drivers, such as the ones required for OpenGL ES and OpenVG. Blitting The use of 2D drivers (blit and fill) is often a popular way to show content on the display, especially if you have a dedicated 2D hardware block. If you use blitting, Screen loads all the drivers for 2D (blitting), OpenGL ES, and OpenVG at one time. It isn't recommended that you use blitting when you need to show content quickly on the display because there's a time cost for starting all the device drivers. Khronos rendering The use of Khronos rendering (hardware rendering with OpenGL ES or OpenVG) causes Screen to start all the drivers for 2D (blitting), OpenGL ES, and OpenVG at one time. Because all device drivers get started at one time, we don't recommend that you use OpenGL ES or OpenVG. If you must use OpenGL ES or OpenVG, consider using precompiled shaders to help reduce the time to show the content on the display. Precompiled shaders are supported with OpenGL ES2 extensions (gles2 modules) and OpenGL ES3. See for more information about shader compilation. Precompiled shaders are specific to a platform, software, hardware, and GPU revision. You can generate the precompiled binary for simple shaders that Screen can use. To generate the shaders, run the screen-gles2-tools utility. The screen-gles2-tools utility generates precompiled binaries that Screen loads when it creates a framebuffer. These precompiled shaders can save the time Screen takes to compile the source before loading it to create a framebuffer. For more information on the screen-gles2-tools utility, see the Utilities chapter in the Screen Developer's Guide , QNX Software Systems Limited

33 Optimize the Splash Screen Application Avoid using a framebuffer When possible, avoid using framebuffers for composition in your splash screen application. You want to avoid using framebuffers (composition) because the operation adds significant time to render an image on a display. You may unknowingly create a framebuffer based on your implementation and what Screen features you use. To find out if your application creates a framebuffer, see the Other Techniques and Troubleshooting chapter. For information about framebuffers, see Configure class subsection in the Configuring Screen chapter of the Screen Developer's Guide. Here are a few techniques to help avoid the creation of a framebuffer in your splash screen application: Because you're using a window buffer for a splash screen application, use a single buffer with a size that matches the video mode that's supported by the display. If you don't use the correct format, this can increase the time it takes to show content on the display. It's important to mention that the list of supported formats that's sent as "supported" to an application doesn't necessarily mean that it works on the display. It's your responsibility to test that it works. The content should be full-screen and if possible, the content shouldn't be scaled. If you want to use an image that is smaller than the full-sized (full-screen) of the display, ensure that the display supports a single window when that window isn't full-sized. With regards to scaling, here are a few things to remember when you want to optimize the time to show an image on the display: Don't downscale a larger image on your system.. We recommend that you downscale the image before putting it onto your system. If you don't, the larger file might increase the time required to load your primary IFS (increased size) and add unnecessary time to downscale and process the image. When possible, use an image with the dimensions to match the resolution display (i.e., no scaling required). If you must upscale, the quality of the image is often poor on high-resolution displays. It's important that you consider the tradeoff between scaling an image and the time to load an image. For example, if you scale a small image to match a higher resolution on the display, the size of the image file is smaller, but you must utilize CPU time to process the image. However, if you don't scale your image, then your image file size is larger, which can increase the time it takes for the primary IFS to load. Ensure that the display controller on the display supports the amount of scaling that you require. Since the buffer is for the splash screen application, ensure that you don't enable protection for the buffer. It shouldn't be necessary and could increase the time it takes to show content onto the display. 2015, QNX Software Systems Limited 33

34 Optimize the Splash Screen Application Optimizing the usage of APIs The use of the SCREEN_PROPERTY_USAGE property indicates how the application intends to use buffers for Screen. Screen doesn t immediately load all the device drivers based on the value of the SCREEN_PROPERTY_USAGE flag. Instead, the device drivers are started when they are first needed by an API call. Therefore, you might experience pausing or stutter because Screen may need time to start a driver if it isn t yet loaded. To improve the time it takes for your application to start, avoid using API calls in your splash screen application that triggers Screen to start devices drivers. For example, avoid making hardware rendering calls because they cause OpenGL ES drivers to start, which are typically slow. Screen starts only the drivers that are required by an API call. For example, if you make a call that requires only 2D hardware (blitter), then only that device driver is started. However, if you make a call that requires both 2D and 3D hardware rendering, then both the 2D and 3D hardware drivers are started, which can significantly increase the time it takes for your content to show on the display. See the table below for the drivers that Screen starts, based on the APIs that are called: Usage flag types Screen Associated Device APIs that Triggers Screen starts Device Driver to start driver Driver? SCREEN_USAGE_NATIVE Yes 2D hardware (blitter) Screen Blit. See Note below. SCREEN_USAGE_OPENGL_ES1 Yes OpenGL ES OpenGL ES 1.X SCREEN_USAGE_OPENGL_ES2 OpenGL ES 2.X SCREEN_USAGE_OPENGL_ES3 OpenGL ES 3.X SCREEN_USAGE_OPENVG Yes 2D hardware (blitter), Screen Blit. See Note OpenVG below. OpenVG SCREEN_USAGE_VIDEO No Video Not applicable SCREEN_USAGE_CAPTURE Capture/Camera SCREEN_USAGE_WRITE SCREEN_USAGE_OVERLAY Yes Display Not applicable Calling screen_flush_blits() or screen_post_window() triggers Screen to start the Blit driver only if screen_blit() or screen_fill() was previously called. Let's say that you need to perform a video capture, but also want to render using OpenGL ES. You can still set the SCREEN_PROPERTY_USAGE property to include the SCREEN_USAGE_CAPTURE and SCREEN_USAGE_OPENGL_ES2 usage flags. The device drivers required for OpenGL ES2 won't load until you make an OpenGL ES 2.X API call , QNX Software Systems Limited

35 Optimize the Splash Screen Application Optimize the usage of windows from Screen We recommend that you use a single, static window buffer (SCREEN_PROPERTY_STATIC) whenever possible. Depending on the size of your image, try to load the image directly into the window buffer. When your application tries to show content from multiple, visible windows, Screen likely needs to create a framebuffer. If your board supports more than one pipeline, you can use the pipelines to avoid the requirement to use framebuffer to do composition. When Screen creates a framebuffer, additional drivers may need to start as well, which can increase the time required to show content on the display. For this reason, to get content shown quickly, we recommend that you minimize the number of visible windows you use in your application. To improve the time it takes to show content on the display, avoid using these unnecessary operations on the splash screen content when possible. Since the contents of the window buffer shouldn't change, set the window's property type to SCREEN_PROPERTY_STATIC. These operations require extra processing time and aren't usually required for a splash screen application: rotation transparency scaling If you use clipped regions in the source rectangle of the window buffer, ensure that the source rectangle (or source view port) is contained within the clipped region. Your clip region should be at least the same size (or larger) so that the source rectangle can be contained within it. So avoid what's shown in the following illustration from occurring: (0,0) Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Ww Xx Yy Zz Source Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nnclip Oo Pp rectangle Qq Rr SsTt UuVv Ww Xx Yy Zz Aa Bb CcDd Ee Ff GgHh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Ww Xx Yy Zz Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt UuVv Ww Xx Yy Zz Aa Bb CcDd Ee Ff GgHh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Window buffer Source rectangle Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk(0,0) Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Ww Xx Yy Zz Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Ww Xx Yy Zz Aa Bb CcDd Ee Ff GgHh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Ww Xx Yy Zz Aa 5 6Bb 7 8Cc 9 Aa DdBb EeCc FfDd GgEe Ff Gg Hh Ii Jj Hh Ii Jj Kk Ll Mm Kk Nn (0,0) Ll OoMm PpNn QqOo Rr Pp SsQq Tt UuVv Rr SsTt UuVv Ww Xx Yy Ww Xx Yy Zz Zz Aa 5 6Bb 7 8CcDd 9 AaEe BbFf Cc Dd Ee Ff Gg Hh Ii GgHh Ii Jj Kk Ll MmJjNn Kk Oo Ll Mm Pp Qq NnRr Oo SsTt Pp Qq UuVv Rr SsTt UuVv Ww Xx Yy Zz Aa Bb CcDd Ee Ff GgHh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Ww Xx Yy Zz Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt UuVv Ww Xx Yy Zz Aa Bb CcDd Ee Ff GgHh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr SsTt UuVv Window Display Figure 8: Avoid - Source rectangle isn't contained within the clipped region. For more information about source clipped regions, see the Using a source clip rectangle section in the Windowing chapter of the Screen Developer's Guide. 2015, QNX Software Systems Limited 35