Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 50 Next »


This page covers the content requirements, abilities, and restrictions of the HTML rendering engine on BrightSign players.

Content Restrictions

The following are content restrictions associated with HTML5 pages:

Web Browsing

BrightSign players are not intended for use as general-purpose web browsers. It is best to think of BrightSign units as HTML5 players with interactive capabilities, not web-surfing tools: Each page should be thoroughly tested before being used as digital signage.

Flash Content

BrightSign players do not support Flash content. Any HTML5 pages that have embedded flash content will not display correctly. Most Flash authoring applications, including the Adobe Creative Suite, have tools that allow you to export flash content as HTML5.

Multiple Video Elements

By default, XT, 4K, and XD players support a maximum of two active <video> elements at any time (HD/LS423 models only support one). You can have more than this amount of <video> elements on a page as long as additional <video> elements have their src attribute set to an empty string. By modifying the src string, you can enable and disable <video> elements on the page.

You can enable Mosiac Mode (using the SetDecoderMode() JavaScript method) to increase the minimum allowed number of <video> elements.

Small Videos

BrightSign players do not support videos that are less than 64 pixels in width or height. However, a video can be scaled down beyond this limit by making the <video> element smaller than 64x64. To get the desired downscaling behavior, ensure that the <video> element does not have the viewmode="scale-to-fill-and-crop" attribute.

4K Graphics

XTx43, 4Kx42, and XDx33 models can display HTML pages using 4K video modes (3840x2160 or 4096x2160).


The XTx43 supports a native 4K HTML graphics plane (see this page for more details). Note the following performance restrictions when using native 4K HTML graphics:

  • Animations will not exceed 20 FPS (and intensive animations may exhibit very low framerates).
  • Non-HWZ video is likewise limited to 20 FPS, so HWZ should be enabled for video elements in native 4K.
  • We recommend displaying only one or two 4K images at a time (for example, a slideshow with a current image and next image preloaded). Images should not exceed 4096x2160 in size. 
  • We recommend using swap memory if possible. 
  • Pages that use many layers may run out of memory in native 4K. Enabling the gfxmemlarge setting may help mitigate this issue.

4Kx42, XDx33

The 4Kx42 and XDx33 support graphics up to 1920x1200 (see this page for more details), which can then be upscaled to a 4K video mode. For the 4Kx42 and XDx33 models, pages must be specified as 1920x1080 (or 2048x1080 for DCI 4K); they can then be upscaled to 4K.

Pixel Sizes and Coordinates with 4K Modes

As noted above, webpages are often upscaled when outputting a 4K video mode. Relative CSS property values will scale automatically, but pixel values may need to be modified to account differences between 4K video and graphics. See here for more information about using coordinates with upscaled video modes.

Image Sizes

Images larger than 2048x1280x32bpp (or 4096x2160x32bpp for XT, 4K, and XDx33 players) will not be displayed by default. If a 4K video mode is used, the player will upscale images from HD resolution accordingly (though native 4K graphics can be enabled on the XTx43). The default limit can be increased in BrightScript using the roVideoMode.SetImageSizeThreshold() method.

Without altering the default maximum resolution, you can increase the maximum width of images by sacrificing height (e.g. using a 4096x640x32bpp image on non-4K players is allowed). You can also increase the maximum width/height by reducing the bpp value (e.g. using a 4096x1280x16bpp on non-4K players is allowed).


For performance reasons, we recommend against downscaling images. This consumes considerably more resources than either displaying images at their native size or upscaling them.

Memory and Performance

The amount of memory available for HTML applications varies by model:

  • XTx43: 512MB for graphics; 512MB for JavaSript

  • XDx33: 256MB for graphics; 512MB for JavaScript
  • HDx23/LS243/HO523: 256MB for graphics; 128MB for JavaScript


  • The memory available for graphics can be reduced by a number of factors, including the number of CSS layers, the complexity of animations, and the use of WebGL.
  • The JavaScript memory is subject to a hard limit: If there is no JavaScript memory after garbage collection, Chromium will terminate the active process.
  • Each HTML widget has its own JavaScript heap, so it's possible to overcommit JavaScript memory if multiple HTML widgets are active.


Often, the best way to improve graphics performance is to ensure that images are scaled to the desired output resoultion before they are rendered in HTML.


Use the Chromium Web Inspector to determine the amount of resources being used by a webpage.

Web Fonts

If a font file is not included and referenced by the HTML page, text will be rendered using a default system font. While functional, the default font has little aesthetic appeal, so we recommend including font files for most digital-signage applications. Supported font types include TrueType Font files (.ttf) and Web Open Font files (.woff.woff2).

DOM Manipulation

We recommend using setAttribute() to manipulate the DOM, rather than using "x.value=y":

	document.getElementById('input-id').setAttribute("value", "name"); //preferred
	document.getElementById('input-id').value = name; //not preferred

Creating HTML5 Pages

Follow these steps when creating HTML5 pages:

  1. Make sure the HTML5 page has the same aspect ratio as your signage display. If you are using HTML5 content in a BrightAuthor zone that is smaller than the screen, fit the page to the same aspect ratio as the zone.
  2. Use a master Div aligned to 0,0 when building an HTML page. This will ensure correct alignment.
  3. When creating an HTML5 site, make sure that all webpage assets (image files, video files, etc.) are contained within the same folder on your local disk. This folder is a “site folder,” meaning that all assets in this folder and its subfolders will be used in the production of the webpage. If these assets are not in the folder, they will not display when the project is published.
  4. You can test the layout and appearance of an HTML5 page locally by opening it with Google Chrome, which has similar rendering capabilites to BrightSign players.
  5. If you want to publish resource-intensive presentations (e.g. <video> elements or multiple transforms) using HTML5, we recommend using a Class 10 (10Mb/s) SD card.

BrightSign Extensions

The BrightSign implementation of the Chromium engine includes several platform-specific extensions. Extensions for <video> elements are covered on the HTML5 Video page.

GPU Rasterization

GPU rasterization is enabled by default in firmware versions 6.2.x and later. To disable GPU rasterization, call ForceGPURasterization(false) on the roHtmlWidget instance used to display the page.

To enable GPU rasterization in earlier versions of firmware, do one of the following:

  • HTML: Add the following meta tag to your HTML page(s): <meta name="viewport" content="width=device-width, minimum-scale=1.0">
  • BrightScript: Call ForceGPURasterization(true) on the roHtmlWidget instance used to display the page.


The rendering engine may not enable GPU rasterization if it determines that the page is not compatible.

Optimized Image Rendering

The image-rendering  CSS property can be assigned the optimizeSpeedBS value. Using this value ensures that Chromium uses lower-quality but faster bilinear filtering when scaling images to 50% or less. We recommend using this value with pages that scale a lot of images at runtime.

Renderer Versions and Support

The following table describes which version of web-rendering engine is used in each version of BrightSign firmware:

Rendering EngineVersionBrightSign FW Versions
Chromium457.0.x, 6.2.x
Chromium376.1.x, 6.0.x
WebKit--5.1.x, 5.0.x, 4.8.x, 4.7.x


You can use this page to determine if specific function calls and extensions are supported in a corresponding version of Chrome.

Animations and Add-on Libraries

This section outlines support for animations and add-on libraries for the Chromium engine on BrightSign players.

JavaScript Animations

Animations that use JavaScript timers, including the JQuery .animate() library, do not make efficient use of GPU resources and are not accurate enough to achieve smooth animations. For this reason, we recommend using CSS animations whenever possible. The JQuery Transit library uses CSS animations and provides an API similar to the .animate() library.


For best results when animating images, we recommend using images at their original size instead of scaling them first. For example, a 480x270 icon will rotate more smoothly if you use an image that is originally 480x270, rather than scaling down a 1280x720 image and then attempting to rotate it.


BrightSign players support the OpenGL API for JavaScript (i.e. WebGL). 


Textures will sometimes fail to load in WebGL because they exceed the maximum allowed image size on BrightSign Players. In these cases, you can use roVideoMode.SetImageSizeThreshold() BrightScript method to increase the maximum size for textures.

Vector Animations

The SVG protocol should be used to specify vector animations.

Canvas Animations

Bitmap animations display smoothly when they are 1/3 or less of a 1080p HTML canvas. Setting the canvas size to 720p allows for larger high-quality animations to occupy the screen.

Push Technology

The long polling technique has been tested and proven to work on BrightSign players.

The Websocket protocol is fully supported via the Node.js implementation on the BrightSign Chromium instance. In production environments, we recommend using HTTPS to initiate Websocket connections with a server (i.e using a WSS connection rather than a WS connection).

File Storage

BrightSign players support several file storage/indexing technologies, including Web SQL, IndexedDB, the HTML Filesystem API, and the JavaScript storage class. The location and size of the web storage database should be set during initialization of the roHtmlWidget.

File Downloads

If you're using JavaScript to download files, we reccomend using the Fetch API and Node.js File System module to perform downloads. See here for more details

CSS Transforms

All CSS transforms should be specified as WebKit transforms. When performing a transform on a <div> or graphics element, you should not specify the transform in-line.

The following code shows an example of an effective CSS transform for a BrightSign player:

@-webkit-keyframes flipon
0% {-webkit-transform:rotateY(0deg);}
30% {-webkit-transform:rotateY(-90deg);}
100% {-webkit-transform: rotateY(360deg);}

Touchscreen Support

BrightSign players are compatible with touchscreens that use standard HID drivers. Note that some manufacturers claim support for HID but still use custom drivers. See this FAQ for further discussion and a list of touchscreen models that have been tested with BrightSign players.

Debugging Webpages 

You can use the Web Inspector to debug webpages over the local network. The Web Inspector can be enabled using BrightAuthor or BrightScript:

  • BrightAuthor: In your BrightAuthor presentation, navigate to File > Presentation Properties > HTML and check the Enable Javascript console box. Once the presentation with HTML content has been published, use Chrome to access the following URL: http://playerIPAddress:2999 (e.g. ).
  • BrightScript: When creating the roHtmlWidget instance, include the inspector_server initialization parameter and specify a port number. You can then use Chrome to access the Web Inspector at http://playerIPAddress:<port>

    If you don't know the player IP address, power on the player with the SD/microSD card (and other storage devices) removed. After a few moments, the IP address will be displayed on screen.


If you're using the Web Inspector to manually step through JavaScript code, enountering an uncaught error in the debugger may cause the player to crash. This is a known bug with the Web Inspector.

Because BrightSign players use an older version of Chromium than recent desktop versions, newer desktop Chrome releases may not work with the Web Inspector. If you're having trouble using the Web Inspector with your version of Chrome, download and install one of these versions:


  • No labels