Introducing Foxlight®

About Foxlight®

Foxlight is somthing that enhances the web. If you are watching a video on YouTube, Foxlight® automatically increses the buffer sped, corrects faults in the video and converts the vieo into HD Quality. What if you are listning to a song? Foxlight® automatically improves the music quality, reduces noise and normalizes the vlume to offer to crisp and clear music.

How does it work

Most of the tasks are pre-programmed into Foxlight®, so you don't have todo anything. But if you want to control Foxlight® 'your way' then you'll need something called Foxlight SDK, which allows you to create scripts called FoxScript®, using which you can control Foxlight® in any way.

Development

Foxlight's development started in early 2009, when Silverlight was just launched. After learning how Silverlight behaves, we decided to make something that offers the dame experinace in a beter way, without reducing quality and zero load on internet speed. Foxlight is being developed by both C++ and Python. The current version of Foxlight (1.0.77.1) was built using C++ and FoxScript®. Python's suppport was removed due to the problems occuring in XCSS Module (xcss.dll), which converts the current CSS of the webpage to XCSS (eXtended Cascading Style Sheets) for faster web loading. The FoxScript® Compiler (fsc.exe) was also being developed on C++ but when the 'BINARY_CONV failed to execute [fsc err 101]' error started cropping up, we redeveloped FSC using C#, which opffered more flexibility and less coding.

Implementation

The current version of Foxlight is being implemented only in Canure (web browser) as Foxlight Developer Tools.

BlixOS Virtual Machine - How it works

What if you use Windows? You can still BlixOS inside a separate environment, without affecting your default Windows environment. Let's see how.

Starting the Virtual Machine -

The VM's icon is on your desktop, you just have to double click it to start the VM. After the VM starts, goto File -> Start BlixOS.

The BlixVM booting

Entering post-boot stage -

When the loading is complete, the VM will enter full-screen mode and the mouse will vanish. The post-boot stage will start. It's here where the boot methods are performed and core boot files are loaded.

Post boot stage

Finally, the boot screen -

After all stages are complete, the boot screen will show up and BlixOS will start booting!

Engineering BlixOS boot screen

When we talk about performance, it present throughout BlixOS. Whether you perform simple tasks such as playing a movie to resource-hungry tasks such as encoding video, you'll always see everything goes on smoothly.

Engineering BlixOS boot logo and boot screen

We started with the BOS boot loader using a different mechanism to display the boot animation. It gets a pointer to the frame buffer from the firmware (either BIOS or UEFI firmware), and displays a higher resolution image (1024 x 768). It animates the image while the kernel and boot critical device drivers are loaded into memory. Since the native graphics driver for the display is not loaded into memory and initialized yet, the animation is run by using the CPU, and by updating the frame buffer for the graphics display. We made an additional optimization - to have the CPU use write-combined caching to accelerate performance.

Another change we made that improved not only the performance of boot, but the quality, was the reduction of transitions in graphics mode. These transitions occur during initialization of the graphics subsystem and Blix shell. In BlixOS Home, these cause the boot experience to be less smooth, as the display changes (flashes black) a few times before presenting the user with a logon screen (or the user’s desktop if there is only one system user).

Making boot screen hardware-independent

The boot experience varies depending on the user’s hardware. We made some design decisions to ensure the best visual experience across a wide range of hardware, however the time it takes a system to get to the desktop is mainly hardware-dependent.

For example, you may notice that there is a delay before the animation starts during boot, and this delay time varies depending on system hardware. To optimize for showing immediate feedback, we actually display text on the boot screen before BlixOS has had a chance to start all the processors on the system. It is only when that is complete that the animation can run asynchronously to the rest of the I/O during boot (which as discussed earlier is necessary for optimal performance and quality).

You may also notice that the BlixOS logo's dimensions during boot may change slightly on different screen sizes. Due to technical constraints in BlixOS, boot is always displayed in our recommended minimum resolution – 1024x768, regardless of the system’s native resolution. Today, most hardware is set to stretch the boot sequence to fill the screen, as opposed to centering it. Consequently, the boot animation is usually stretched on screens that are of different aspect ratio than 1024x768; however, we did test the sequence on common aspect ratios to ensure that visual quality was preserved.

Boot, Resume, Hibernate

With all this hard work to improve the boot experience, we couldn’t let it go to waste. As such, users will also have this experience when they resume from hibernate.