CE.SDK runs entirely on clients and makes use of hardware acceleration provided within that environment. Therefore, the user’s hardware always acts as an upper bound of what’s achievable.
The editor’s performance scales with scene complexity. We generally found scenes with up to 200 blocks well usable, but complex blocks like auto-sizing text or high-resolution image fills may affect performance negatively. This is always constrained by the processing power available on the user’s device, so for low-end devices, the experience may suffer earlier. Therefore, it’s generally desirable to keep scenes only as complex as needed.
Hardware Limitations#
Each device has a limited amount of high performance hardware decoders and encoders. If the maximum number is reached it will fall back to (slow) software de- and encoding. Therefore users may encounter slow export performance when trying to export in parallel with other software that utilizes encoders and decoders, e.g. Zoom, Teams or video content in other tabs / apps. This, unfortunately, is a limitation of hardware, operating system and browser and cannot be solved.
Recommended Hardware#
| Platform | Hardware |
|---|---|
| Desktop | A notebook or desktop released in the last 7 years and at least 4GB of memory. |
| Mobile (Apple) | iPhone 8, iPad (6th gen) or newer |
| Mobile (Android) | Phones & tablets released in the last 4 years |
Video#
Our video feature introduces additional requirements and we generally distinguish playback (decoding) and export (encoding) capabilities. On the web, certain browser features directly depend on the host operating system. For video, this currently introduces the following limitations:
- Transparency in H.265 videos is not supported on Windows hosts.
- Chrome on Linux has no AAC encoder. A video export from it writes an MP4 with H.264 video and Opus audio.
- Firefox supports video editing and video export starting with version 130 via the WebCodecs API. Firefox has no AAC encoder, so a video export from it writes an MP4 with H.264 video and Opus audio.
- Chromium although technically the base of Chrome doesn’t include any codecs for licensing reasons and therefore can’t be used for video editing. It does fall back to system-provided media libraries on e.g. macOS, but support is not guaranteed in any way.
- Linux browsers generally have limited video support due to codec licensing. A video export needs an H.264 encoder and an AAC or Opus encoder in the browser, and some open-source builds have no H.264 encoder.
- Video is not supported on mobile browsers on any platform due to technical limitations which result in performance issues.
To detect these limitations at runtime, run the video.decode.checkSupport and video.encode.checkSupport actions. Each measures the codecs on first use and then answers; pass { dialog: false } to stay silent.
Color Picker#
The color picker’s eyedropper (“Pick color from screen”) uses the browser’s EyeDropper API. CE.SDK shows the button only where that API exists.
- Only desktop Chromium-based browsers such as Chrome and Edge have it, so the button is absent in Firefox and Safari.
- On Linux, Chromium has the API on both X11 and Wayland, so the button appears. Chromium reads the pixel by capturing the screen. On Wayland that capture needs permission through the desktop portal, so a screen-sharing prompt appears and the request often fails. On X11 the capture can return a wrong color. Neither case shows an error message.
Users can enter a hex value or use the RGB sliders instead.
Export Limitations#
The export size is limited by the hardware capabilities of the device, e.g., due to the maximum texture size that can be allocated. The maximum possible export size can be queried via API, see export guide.