Comparing Wayland and X11 DisplayServer Protocols in Full-screen

Applications

Michail Augaitis

Project Supervisor: Daniel Nesbitt

Computing ScienceDate: May 2019

Word count: 13412

Abstract

Most current desktop Linux systems utilise a display server protocol called X11, this protocolhas become convoluted and not fit for a modern system. There are other protocols that aimto replace the contemporary graphics environment and to solve the issues presented by it.One such protocol is Wayland, it is supposed to be a simpler replacement for X which is alsosupposed to simplify the graphics stack and therefore increase rendering performance. Thisproject aims to analyse and check the validity of these claims by developing a game that willrun optimally on both display server protocols, then testing the performance of said game ona number of X11 and Wayland compositors. Additionally, this project aims to provide insightinto how Wayland works and how it tries to improve the Linux desktop experience.

Declaration

“I declare that this dissertation represents my own work except where otherwise stated.”

Acknowledgements

Firstly I would like to thank Daniel Nesbitt for providing his invaluable guidance, insights andLinux expertise throughout the project. Additionally, I would like to thank Rich Davison forhelping with any game development queries I had throughout the project.

1

Contents

1 Introduction 5

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Project Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Research 8

2.1 Research Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Background Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Linux Graphics Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 History of Windowing systems . . . . . . . . . . . . . . . . . . . . . . 9

2.2.3 X.Org/X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.4 Wayland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.5 Compositor Programming Language (C) . . . . . . . . . . . . . . . . . 15

2.2.6 Video Game Programming Language (C++) . . . . . . . . . . . . . . . 15

2.2.7 Wlroots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.8 Build Tools (Meson, CMake) . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.9 Game Development Library (Simple DirectMedia Layer) . . . . . . . . 16

2.2.10 Version Control (Git, GitHub) . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.11 Microsoft Visual Studio, Visual Studio Code . . . . . . . . . . . . . . . 17

2.2.12 Compilers (Clang, Microsoft C++ Compiler) . . . . . . . . . . . . . . . 17

3 Methodology 18

3.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.1 Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2 Testing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Development 21

4.1 Development Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Wayward (Wayland Compositor) . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.1 Versions of software used . . . . . . . . . . . . . . . . . . . . . . . . . 23

2

4.2.2 Wlroots Set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.3 Creating the Compositor . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 SDL2 Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.1 Versions of Software used . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.2 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.3 Creating the Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4 Porting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.1 Porting to X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.2 Porting to Wayland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Testing 31

5.1 Compositor Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Measuring Performance on X11 . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Measuring Performance on Wayland . . . . . . . . . . . . . . . . . . . . . . . 34

5.4 Measuring Performance on Windows . . . . . . . . . . . . . . . . . . . . . . . 37

5.5 Other Discrepancies Between Protocols . . . . . . . . . . . . . . . . . . . . . 37

6 Evaluation 39

6.1 Protocol Performance Comparison . . . . . . . . . . . . . . . . . . . . . . . . 39

7 Conclusion 42

7.1 Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.2 Reflection on Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Appendices 45

Software Developed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Glossary 47

References 51

3

List of Figures

1 Abstraction of the Linux GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Architecture of X11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Architecture of Wayland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 GANTT chart of the initial work plan . . . . . . . . . . . . . . . . . . . . . . . 19

5 Running ’weston-info’ on Wayward, listing all global objects . . . . . . . . . . 24

6 Running LibreOffice on Wayward . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Class Diagram of Daunting Dungeon, Automatically Generated using VisualStudio Class Designer[66] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

8 Daunting Dungeon: the video game developed, running on I3 window manager(X11). Game assets by HorusKDI[67] and 0x72[68] . . . . . . . . . . . . . . . 28

9 FPS Counting Class, Diagram Automatically Generated using Visual StudioClass Designer[66] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

10 Test Frame Rate on I3(X11), Average FPS: 317.1 . . . . . . . . . . . . . . . . 32

11 Test Frame Rate on KWin(X11), Average FPS: 318.47 . . . . . . . . . . . . . 33

12 Test Frame Rate on Mutter(X11), Average FPS: 309.413 . . . . . . . . . . . . 33

13 Test Frame Rate on Sway(Wayland), Average FPS: 323.77 . . . . . . . . . . 34

14 Test Frame Rate on Wayward(Wayland), Average FPS: 60 . . . . . . . . . . . 35

15 Test Frame Rate on Weston(Wayland), Average FPS: 329 . . . . . . . . . . . 36

16 Test Frame Rate on Mutter(Wayland), Average FPS: 319.283 . . . . . . . . . 36

17 Test Frame Rate on Windows 10, Average FPS: 181.71 . . . . . . . . . . . . 37

18 Graph of all tested compositors’ FPS . . . . . . . . . . . . . . . . . . . . . . . 39

19 Graph Comparison of Test Frame Rate on Sway and I3 . . . . . . . . . . . . 40

20 Graph Comparison of Test Frame Rate on Mutter Wayland and X11 backends 41

21 Graph Comparison of Test Frame Rate on KWin and Weston . . . . . . . . . 41

4

1 Introduction

This section aims to familiarise the reader with the dissertation and explain its purpose,motivation and value of the project.

1.1 Motivation

Most Linux and Unix-based systems rely on the X Window System (or simply X) as the low-level protocol for building graphics interfaces. On these systems, the X stack has grownto encompass functionality arguably belonging to the kernel and self-contained libraries. Xhas incorporated a lot of modern features like off-screen rendering and scene composition,but subject to the limitations of the X architecture. For example, the X implementation ofcomposition adds additional context switches and makes things like input redirection difficult.

In general, the X server is now just a middle man that introduces an extra step betweenapplications and the compositor, and an extra step between the compositor and the hard-ware.[1]. Wayland is a modern replacement for X, it simplifies the graphics stack by havinga compositor as the display server, whereas in X a compositor is separate and needs tocommunicate to the X server before rendering the screen [1] . Wayland was designed toreplace X11 and solves a lot of the issues introduced by it:

1. Isolation – unlike X, there is no shared coordinate space for clients. Wayland clientscannot snoop on each other’s input or inject fake input events. They cannot draw oneach other’s windows or cover up windows with fake replicas. This makes Wayland amuch better choice of display protocol when isolating untrusted applications.

2. Baggage – Wayland tries to retain only the functionality that is still used by the modernLinux desktop.

3. Extensibility – Wayland is a simpler and less convoluted project than X which means itis a good basis to enable features that are hard to support under X[2].

4. Performance – With a simplified graphics stack Wayland is supposed to render thescreen faster and remove screen tearing.

There are companies and communities that have already begun implementing Wayland. Forexample, latest versions of Ubuntu allow switching to a Wayland session [3] and KDE isworking on turning their window manager KWin into a Wayland compositor [4] . However,they are hindered by requiring backward compatibility to support X11 applications. In order todo so Wayland must essentially run an X11 client on top of a Wayland client which incurs aperformance penalty.

1.2 Purpose

The purpose of the project is to study performance differences between a Wayland com-positing window manager, that does not rely on X, over the contemporary X11 graphicalenvironment, thus contributing to the open source community as it will offer an insightfulcomparison of both Wayland and X11 performance in a full screen application, namely avideo game. Another objective of the project is to provide more insight into how Waylandworks by creating a simple Wayland compositor, analyse issues with X11 and the need for amodern display server protocol. This will hopefully facilitate the change towards a moderndisplay server protocol for Linux. In addition, this project will provide insight into methods ofporting an application to Wayland.

5

1.3 Project Aims and Objectives

The overall aim of the dissertation is to create the tools to allow for a detailed analysis ofWayland and X11 compositors. The tools created during this project will be used to run testson a number of different X11 and Wayland compositors and measure the performance ofeach one. The test results and research conducted throughout the project will be used tomake comparisons of both protocols and provide insight into their differences. The tasksrequired to achieve this aim are split into several objectives:

1. Create a Wayland compositor – said compositor will not support X11 and as a resultwould be utilising all the advantages of a simplified graphics stack. The compositor willbe developed using wlroots, a modular Wayland compositor library[3]. A successfulimplementation of the Wayland compositor would be such that it would be able to runonly native Wayland applications and would incorporate all the basic functionality of acompositor.

2. Create a cross-platform video game using an OpenGL-based engine, then port thegame to Linux for Wayland and Xorg – the video game will be used as a benchmark tocompare both display server protocols. The researcher’s choice of semester 1 modulesincludes CSC3223 - Graphics for Games and CSC3221 - Programming for Gameswhich will aid the development process in semester 2. The game engine and videogame will be developed as part of CSC3224 - Computer Games Development module’scoursework. The video game created in mentioned module will be adapted to run onLinux in both X11 and Wayland environments.

3. Benchmark game with the Wayland compositor developed and contemporary X11graphical environment – this objective will require both previous tasks to have beencompleted. It will involve running the developed video game on a Wayland compositorcreated and an X11 window manager. The performance of both scenarios will beanalysed and compared, taking note of any other advantages one has over the other.

4. Benchmark the game on other Wayland and X11 compositors - in addition to comparingthe performance of the video game on the developed Wayland compositor, the videogame will be run on a number of already developed X11 and Wayland compositorsin order to get a better understanding of the current state of Wayland on currentlydeveloped compositing window managers.

In addition to the main objectives mentioned above, the video game developed will bemeasured on Microsoft Windows 10 in order to have a cross-platform comparison andevaluate the game’s porting process as it will be initially developed on Windows 10.

1.4 Dissertation Outline

The Introduction section describes the motivation and purpose of the project, outlines theaims that this project sets out to achieve.

The Research section provided a detailed review of the research conducted for this projectand explains a lot of concepts required for further stages of the dissertation.

Methodology section describes the plan and schedule of the dissertation and the tools usedto achieve the set out goals.

Development section explains the process of developing the Wayland compositor and videogame required for this project. Additionally, it explains the steps required to port the SDL2

6

video game from Windows 10 to X11 and Wayland.

The Testing section presents the results gathered using the tools developed for this projectusing graphs and discusses any other findings while testing.

The Evaluation section assesses the state of the display server protocols tested and tries todetermine which protocol performed better.

The Conclusion section talks about the outcome of the project, reflects on the aim of thedissertation, discusses issues and mistakes made and how they could have been avoided ormitigated. This section also discusses future work that could be done on the subject.

7

2 Research

This section covers the research undertaken and discusses the concepts necessary for thisproject in more detail.

2.1 Research Strategy

The research was conducted in the following order:

1. Explore problem areas of current X11 compositors.

2. Research how Wayland could solve these issues.

3. Think of a method to test if Wayland can improve upon X11.

4. Research tools required for said method.

The area X11 struggles in is running full-screen applications such as video games due toX11 introducing unnecessary steps in the graphics stack, therefore research was conductedon how Wayland could improve on this area. The further research sections discuss how, intheory, Wayland solves some issues present in the current X11 graphical environment.

For the tools required the researcher aimed to find a cross-platform video game developmentlibrary that would have Wayland support in order to minimise the effort of porting the videogame to Wayland, and a reliable development library to create the Wayland compositor.

2.2 Background Research

This section talks about the research conducted for this project.

2.2.1 Linux Graphics Stack

Before discussing display server protocols in-depth it is necessary to understand what theyare and their purpose. This section presents a simplified summary of how Linux renders theGUI (see Figure 1 for illustration).

A display server or window server is a program whose primary task is to coordinate the inputand output of its clients to and from the rest of the operating system, the hardware, and eachother. The display server communicates with its clients over the display server protocol.[4]

Display server protocols or communication protocols specify the communication between adisplay server and its clients.[1]

A window manager is system software that controls the placement and appearance ofwindows within a windowing system in a GUI.[5] Additionally, what window managers arereferred to can be logically divided into two layers: a window manager, which provides theuser interface, and a window system, which provides the functional or programming interface.The window system provides procedures that allow an application to draw images on thescreen and get input from the user. The window manager allows the end user to movewindows around and is responsible for displaying the title lines, borders and icons around thewindows.[6]

Window managers can also provide compositing. These kinds of window managers are calledcompositing window managers or compositors. They provide applications with off-screenbuffers, meaning that if an application becomes unresponsive, it will not affect the rest of the

8

applications. The window manager composites the window buffers into an image representingthe screen and writes the result into the display memory.[7] Compositors may additionallyprovide graphic effects and animation, shadows, transparency, advanced lighting techniquesand other rich visual features on the desktop.[8]

Figure 1: Abstraction of the Linux GUI(source: http://turlucode.com/

arch-linux-install-guide-step-2-desktop-environment-installation/#Cinnamon)

2.2.2 History of Windowing systems

The first windowing systems were implemented as part of a single program or system, forexample the Emacs text editor had its own windowing system. Later systems implementedthe windowing system as an integral part of the operating system such as Sapphire forPERQs[9], Macintosh and Windows systems. In order to allow different windowing systemsto operate on the same operating system, some window systems, such as X, operate as aseparate process and use the operating system’s interprocess communication mechanism toconnect to applications.[6]

First integrated window managers were stacking window managers, also referred to asfloating window managers, which meant that all windows were drawn in a specific order,allowing them to overlap. There are issues with this approach, for example, a maliciousprogram can cause the system to appear unstable by simply neglecting to repaint its window.Additionally, if an application becomes unstable, it may fail to redraw itself which sometimescauses the area within the window frame to retain images of other windows when it is broughtto the foreground. This problem is commonly seen on Windows XP and earlier, as well assome X window managers.[10]

To solve the issues presented by stacking window managers, a compositing window managerwas developed, which solved some of said issues (as mentioned in section 2.2.1). One ofthe first systems with a compositing windowing system was the Commodore Amiga whichwas released in 1985. Applications could first request a region of memory outside the current

9

display region for use as a bitmap. The windowing system would then composite thesebitmaps without requiring the applications to redraw any of their bitmaps.[11]

Compositing window managers have become standard on modern desktop systems. AppleInc. developed the Quartz Compositor for macOS in 2001.[12] Microsoft introduced theDesktop Window Manager in 2007 as their window manager for Windows Vista and allfollowing versions of Microsoft Windows.[13]Arguably the two most popular Linux desktopenvironments also use compositing window managers: GNOME desktop uses Mutter[14],KDE desktop environment uses KWin[15]. Both of these compositing window managers usethe X window system as X has been the most popular Linux window system for many years.During these years there was a number of display server protocols that tried to improve uponX and overtake it as the most popular desktop windowing system, such as DirectFB, XynthWindow System and Fresco[16]. One of more noteworthy attempts was the Y window system.It was developed specifically to address the issues with the X window system and ultimatelyreplace it. According to the Y window manager’s beta release paper, Y ”sets out to redressmany of the problems reported by users of the X window system, and in particular the relatedproblems of screen clutter and icon underload”.[17] The Y window system did not manageto gain enough traction to overtake X and eventually ceased development. However, at themoment another display server protocol is trying to replace X11. That display server protocolis called Wayland. Developed in 2008 and, just like the Y window manager, is designedspecifically to replace X. Wayland saw its first stable version in August 2018[18] and is gaininga lot of popularity. Even compositors such as previously mentioned KWin and Mutter currentlyare in the process of being converted to Wayland compositors.

Mark Shuttleworth, the founder and CEO of Canonical Ltd., the company behind Ubuntu, hasexpressed his opinion on the state of X11 and in his blog post about the future of the GNOMEdesktop, stating ”Progress on Wayland itself is sufficient for me to be confident that no otherinitiative could outrun it” and ”We don’t believe X is set up to deliver the user experience wewant”[19]. Due to these popular desktop environments gradually moving towards Wayland, itis thought to be a replacement for current X11 graphical environment.

2.2.3 X.Org/X11

X.Org Server is the free and open-source implementation of the display server for the XWindow System stewarded by the X.Org Foundation.[20] Founded in 1984 by Jim Gettys andBob Scheifler at the Massachusetts Institute of Technology in Boston.

The design principles of X Window Systems according to Scheifler and Gettys were(1986)[21]:

1. The system should be implementable on a variety of displays.

2. Applications must be device independent.

3. An application that runs on one machine must be able to use a machine that is connectedto another machine on the network.

4. The system must support multiple applications displaying concurrently.

5. The system should be capable of supporting many different application and manage-ment interfaces.

6. The system must support overlapping windows, including output to partially obscuredwindows.

10

7. The system should support a hierarchy of resizeable windows, and an application shouldbe able to use many windows at once by providing a true window hierarchy.

8. The system should provide high-performance, high-quality support for text, 2-D syntheticgraphics, and imaging.

9. The system should be extensible, communities should be able to extend the system bytheir own, but they should be merged with the core seamlessly.

X window system (also called X11 or X) is a basis for graphical user interface. It is responsiblefor drawing windows, icons, menus and pointers of the screen. The system consists of:

1. Client(Application) - The X Client is the application that is running. Its main task is toprovide data to the clients.

2. X Server - it is the local machine that is connected to the X Client to display the programit is running. The Server contains the libraries that are specific for the types of hardwareon that system. The global data that is generated by the client is passed to the server,which makes it machine specific so that it can handle it on its own machine.

3. X Window Core Protocol - sends messages over the network such as:

• Request: The client is requesting information from the server or it is requesting toperform some action, like creating a new window.

• Replies: The response from the server on a request by the client.

• Events: Information about any user activity (hardware movement,window moved/resized/exposed etc.) is sent from the server to the client.

• Errors: If a request is invalid, the server sends an error to the client.

4. Window manager - The GUI exists of a top-level-window and it covers the whole screen.Within this top-level-window, other windows are allowed, sub-windows. A window canonly be generated as a sub-window of a parent-window. Therefore, a hierarchy ofwindows exists, which can be stored in a tree.[21]

Figure 2 shows the steps needed for an event to display changes on the screen. These stepsare as follows:

1. The kernel gets an event from an input device and sends it to X through the input driver.

2. The X server determines which window the event affects and sends it to the clients thathave selected for the event in question on that window.

3. The client looks at the event and decides what to do.

4. When the X server receives the rendering request, it sends it to the driver to let itprogram the hardware to do the rendering.

5. The damage event tells the compositor that something changed in the window and thatit has to recomposite the part of the screen where that window is visible.

6. The X server receives the rendering requests from the compositor and either copies thecompositor back buffer to the front buffer or does a pageflip. In the general case, the Xserver has to do this step so it can account for overlapping windows, which may requireclipping and determine whether or not it can page flip.

Despite being the most commonly used window system, X has a number of issues. The”Unix-Haters Handbook”, written by Simson Garfinkel[22], sternly criticises X as a graphical

11

Figure 2: Architecture of X11

12

environment. Garfinkel argues that X is a bloated and memory-intensive window system, witheven the smallest X11R4 “xclock” utility consuming 656KB of memory to run. Additionally, thebook raises issues with X window system’s ease of use, customisability, portability, deviceindependence and further development. A number of developers have expressed frustrationwith development of X due to a lack of design guidelines, which resulted in several vastlydifferent interfaces and applications that have not always worked well together[23].

Another concern with X window server’s design is security. X protocol is network-based andwas designed with compatibility and performance in mind, not security. The security threatscan be broadly classified into traditional security property categories of confidentiality, integrityand availability. Confidentiality is violated because standard X servers offer no protectionfor an application’s output. Malicious application can currently probe the entire state of theX server. Integrity is broken due to clients being able to draw directly into another client’swindow and can send input or any other kind of event directly to a client. For example, amalicious client can cause another client to present false information to the user. Availabilityis infringed upon because of X client’s ability to close the windows of other clients, manipulatethe font lists and manipulate the host access list[24]. While all these issues can be preventedor at least mitigated, having said security concerns in the protocol is concerning and hasmotivated the open source community to develop an alternative window system.

The X.Org foundation has acknowledged the problems with X11, stating ”X11 was designedfor a different era of computing” and have laid out requirements for a successor for X11 -”X12”. Some of the points mentioned are that X12 should remain network-transparent, havemore parallelism, have compositing by default, just like Wayland, and optimise input handling.However X12 is not in development, meaning that the leading project working towards amodern windowing system is still Wayland.[25]

2.2.4 Wayland

Wayland is a free and open source community-driven display server protocol developed byKristian Høgsberg and other volunteers with the aim of replacing the X window system. Adisplay server using the Wayland protocol is called a Wayland compositor.[1]

Wayland tries to retain only the functionality in the X server that is still used by the modernLinux desktop. Overall, the philosophy of Wayland is to provide clients with a way to managewindows and how their contents are displayed. Rendering is left to clients, and system widememory management interfaces are used to pass buffer handles between clients and thecompositing manager.

As mentioned in section 2.2.2 Wayland was developed with the purpose of addressing issuespresent in X11 and replace it. Wayland achieves this by simplifying the graphics stack byhaving a compositor as the display server, whereas in X a compositor is separate and needsto communicate to the X server before rendering the screen[1]. Additionally, Wayland tries tosolve the following issues:

• Isolation – unlike X, there is no shared coordinate space for clients. Wayland clientscannot snoop on each other’s input or inject fake input events. They cannot draw oneach other’s windows or cover up windows with fake replicas. This makes Wayland amuch better choice of display protocol when isolating untrusted applications.

• Baggage – Wayland tries to retain only the functionality that is still used by the modernLinux desktop.

13

• Extensibility – Wayland is a simpler and less convoluted project than X which means itis a good basis to enable features that are hard to support under X[2].

• Performance – With a simplified graphics stack Wayland is supposed to render thescreen faster and remove screen tearing.

Figure 3: Architecture of Wayland

Figure 3 follows an event from the input device to the point where the change it affectsappears on screen. The steps in this figure are as follows:

1. The kernel gets an event and sends it to the compositor.

2. The compositor determines which window should receive the event.

3. A Wayland client receives the event. The rendering happens in the client, after is it donerendering it sends a request to the compositor to indicate which region was updated.

4. The compositor collects all the changes and recomposites the screen.

The adoption of Wayland seems to be controversial at the moment with a lot of Linux usersclaiming that Wayland does not solve most of the issues it is supposed to solve and is

14

incapable of supporting certain features, such as clipboard managers or screen capturing,that are present in X11. The developer of wlroots has made a blog post explaining themisconceptions about the current state of Wayland. Drew DeVault clarifies that most featuresthat are missing from Wayland but are present in X11 can be implemented, but have notyet been due to Wayland being a new protocol. He also notes that one of the criticisms isactually true: Wayland is not network transparent. However Wayland can achieve networktransparency throught Xwayland - a compatibility layer for X11. The advantage of not beingnetwork transparent is that Wayland compositors can render clients without copying data onthe GPU - which improves performance dramatically. Additionally there are issues with driversupport from a certain manufacturer, namely Nvidia Corporation, for Wayland, which shouldbe resolved if Wayland gains more traction[26].

Another feature Wayland lacks, compared to X11, is portability. Wayland was developedspecifically for Linux. This means that Wayland can run on all devices that Linux can runon, such as phones and kiosks[27], however it cannot run on systems such as MicrosoftWindows operating systems or Mac OS. While X11 does not run on Windows[28] or MacOS[29] natively, there is software that enables it to run on different operating systems. Thereis no indication that Wayland cannot support other operating systems, however, with FreeBSDcurrently working on supporting Wayland by default[30].

2.2.5 Compositor Programming Language (C)

C is the programming language used to create the compositing window manager for thisproject. C is a general-purpose, imperative computer programming language, created in1972 by Dennis Ritchie. By design, C provides constructs that map efficiently to typicalmachine instructions, meaning that it is useful for applications that have previously beenwritten in assembly, such as operating systems and software for embedded systems[31]. TheC programming language is the result of Dennis Ritchie improving on the B programminglanguage, which is a collaborative work of Ken Thompson and Dennis Ritchie[32]. Thislanguage was chosen for developing the compositor due to wlroots being written in C itselfand for the software engineering experience of using C in development.

2.2.6 Video Game Programming Language (C++)

C++ is a general-purpose programming language that was developed by Bjarne Stroustrupas an extension of the C language. It is a generic and object-oriented programming lan-guage which also provides facilities for low-level memory manipulation, It is almost alwaysimplemented as a compiled language, which means that the implementations of C++ areusually compilers. C++ was developed with compatibility with C in mind to have sufficientperformance and flexibility for even the most demanding systems programming. In his FAQStroustrup mentions that he wanted to create a ”better C” language. C++ is ”a better C” inthe sense that it supports the styles of programming done using C with better type checkingand more notational support (without loss of efficiency). To quote Stroustrup ”I have neverseen a program that could be expressed better in C than in C++ (and I don’t think such aprogram could exist - every construct in C has an obvious C++ equivalent)”. This programminglanguage was chosen for developing the video game used in this project as C++ is a languagethat is predominantly used in the video game industry.

15

2.2.7 Wlroots

Wlroots is a library of pluggable, composable, modules for building a Wayland compositor.Wlroots provides backends that abstract the underlying display and input hardware, mostlystandalone implementations of many Wayland interfaces. The development library providesan Xwayland abstraction that allows for excellent Xwayland support. Wlroots is developedunder the direction of the sway project - a Wayland compositor that is compatible with theX11 compositor I3. Additionally, Wlroots provides a number of wrapper libraries for otherprogramming languages[3].

Another option that was considered for this project was libweston. It is an effort to separatethe re-usable parts of Weston, the reference compositor for Wayland, into a library. Libwestonfocuses on correctly implementing core Wayland protocols and interfacing with input andoutput systems so that the user could focus on creating features that make their compositorunique[33].

The reason libweston was not chosen as the development library for this project was becauseit has known bugs and shortcomings and[33] because wlroots seems to have a larger followingand is trying to become a standard for developing Wayland compositors. wlroots is evenseeing adoption in mobile applications. Purism, a social purpose company, are developing analmost entirely open source, Linux smartphone which is going to use Wlroots and Waylandfor its UI[34].

2.2.8 Build Tools (Meson, CMake)

Different build systems were used in order to build the compositor and the video game. TheWayland compositor used Meson and Ninja in order to build the project. Meson is an opensource build system that focuses on speed, user friendliness and uses Ninja by default[35].Ninja is a small build generator with a focus on speed, it is designed to run builds as fast aspossible. Ninja’s low-level approach makes it perfect for embedding into more powerful buildsystems, such as Meson or CMake[36]. These tools were chosen for building this project dueto their performance and ease of use.

The video game developed for this project uses CMake and GNU Make for its build system.CMake is an open-source, cross-platform family of tools designed to build, test and packagesoftware. CMake is used to control the software compilation process using simple platformand compiler independent configuration files, and generate native makefiles and workspacesthat can be used in the compiler environment of the user’s choice. The suite of CMaketools were created by Kitware in response to the need for a powerful, cross-platform buildenvironment for open-source projects[37]. GNU Make is a tool which controls the generationof executables and other non-source files of a program from the program’s source files[38].The reason these tools were chosen for the video game is due to CMake and GNU Makebeing well documented for building SDL2 projects.

2.2.9 Game Development Library (Simple DirectMedia Layer)

Simple DirectMedia Layer is a cross-platform development library designed to provide lowlevel access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL andDirect3D. SDL2 is written in C, works natively with C++. SDL2 was chosen for developing thevideo game mainly because it is simple to implement and has Wayland support, specificallysupport for the XDG shell that is most often used in Wayland compositors for desktopenvironments[39](XDG shell is further explained in section 4.2.3).

16

The SDL2 library has other extension libraries that allows for additional functionality. Thevideo game developed uses two additional extension libraries: SDL IMAGE and SDL TTF.SDL IMAGE is an image file loading library made by Sam Lantinga and Mattias Engdegard.It enables loading of images as SDL surfaces and textures[40]. SDL TTF is a library thatallows the user to use TrueType fonts in SDL applications[41].

Another options for a game development library was SFML. It is a simple, fast, cross-platformand object-oriented multimedia API. It provides access to windowing, graphics, audio andnetwork. It is written in C++, and has bindings for various programming languages. Onekey issue with SFML is that it has no Wayland support which is essential for this project.Alternatively, using pure OpenGL was considered as well, however SDL2 provides mosttools necessary for a game of the scope required for this project. OpenGL would have anadvantage over pure SDL2 if the game required the use of shaders[42] and the video gameis meant to use pure SDL2 in order to maximise Wayland compatibility.

2.2.10 Version Control (Git, GitHub)

Git is a free and open source distributed version control system designed to handle everythingfrom small to very large projects with speed and efficiency. Git is the most widely usedmodern version control system in the world, it was originally developed in 2005 by LinusTorvalds, the famous creator of the Linux operating system kernel. Git has been designedwith performance, security and flexibility in mind[43].

GitHub is a Git repository hosting service. GitHub provides a Web-based graphical interface.It also provides access control and several collaboration features, such as wikis and basictask management tools for every project[44]. Both of the projects (the Wayland compositorand video game) will be hosted on GitHub and available publicly.

2.2.11 Microsoft Visual Studio, Visual Studio Code

Visual Studio is a proprietary IDE (Integrated Development Environment) from Microsoftthat is used to develop software. It includes a number of features such as code completion,refactoring components, an integrated debugger. It is a comprehensive suite of virtually alltools needed for software development, analysis, testing and deployment[45].

Visual Studio Code is an open source, more cross-platform version of Visual Studio. Itprovides similar features to Visual Studio, however it is not considered a full IDE, but rather atext editor with optional plug-ins to extend its functionality[46].

2.2.12 Compilers (Clang, Microsoft C++ Compiler)

Microsoft C++ Compiler is the compiler that Visual Studio uses by default for compiling c++applications. This compiler is targeted at applications intended to run on Microsoft Windowsoperating systems.

Clang is an open-source cross-platform is a compiler front end for the C, C++, Objective-Cand Objective-C++ programming languages. Microsoft recommends using Clang to targetLinux, Android, iOS and Windows platforms[47].

17

3 Methodology

This section provides an overview of how the dissertation was planned out, what tasks werecarried out and what tools were used in order to achieve the aims of this dissertation.

3.1 Planning

Figure 4 is a diagrammatic representation of the initial plan outlining tasks for the rest of theproject and time allocated to each one. It is a Gantt chart created using an online Gantt chartsoftware by TeamGantt[48]. The schedule on the Gantt chart was mostly adhered to, howeverthe requirements and the aims have changed throughout the project and therefore it was notpossible to strictly follow the goals set out in the initial plan. The changes made during theproject are discussed in detail in section 7.2.

The general plan for the dissertation was to do most of the research on the technologiesrequired, set up the development environments and to start the write-up for the dissertationduring the first semester of the academic year. ”Objective 1” in the Gantt chart refers to thefirst objective in the ”Project Aims and Objectives” section, which is to create a Waylandcompositor. ”Objective 2” is to create a cross-platform video game and ”Objective 3” is tobenchmark the game on various platforms. Most of the development and benchmarking wasdone during semester 2, just as outlined in the Gantt chart. Additionally, weekly meetingswere held with the dissertation supervisor in order to resolve any issues and ensure that theproject is following the work plan.

Contingency plans: in case of failing to develop a Wayland compositor, an already createdcompositor would be used to benchmark the game. In case of failing to develop a cross-platform video game, another, already made application, such as Mozilla Firefox Nightly[49],would be used to benchmark the performance of both display server protocols.

18

Figure 4: GANTT chart of the initial work plan

3.2 Risks

Primary risks and issues involving this project were driver support and feature instability dueto Wayland being fairly new. Currently there are issues with Nvidia Corporation delayingWayland support in their proprietary drivers. This issue is constantly evolving, however, withNvidia releasing plans of supporting Wayland in the near future[50]. Due to instabilities withNvidia’s Wayland support, the project is going to focus instead on developing the compositorfor an Intel graphics card which would also benefit the AMD graphics environment as AMD hasproper open source drivers and Wayland support[51]. Additionally, most Wayland compositorsare in active development and are not considered stable, this means that some features couldhave bugs and not work properly.

3.3 Tools

The entire development and testing process was performed on a an Asus Zenbook UX303Llaptop[52] with the following specifications:

• Intel R© CoreTM i7 6500U Processor

• Arch Linux and Windows 10 Operating systems

• DDR3L 1600 MHz SDRAM, OnBoard Memory 4 GB

• PS FHD (1920x1080) Display

• NVIDIA R© GeForce R© 840M with 2GB DDR3 VRAM GPU

3.3.1 Development Tools

The Wayland compositor was developed on Arch Linux, using Visual Studio Code as thetext editor/IDE and C as the programming language. The Compositor uses Wlroots as itsdevelopment library, Meson as the build system and Ninja as the build maker.

19

The video game was written using C++. It was initially developed on Windows 10 using VisualStudio, but was later moved to Arch Linux, using Visual Studio Code. On Windows 10 thegame used Microsoft C++ Compiler for building and compiling the project. On Arch Linux thecompiler was Clang, CMake and GNU Make were used as the build system. Additionally, thevideo game depends on a number of dependencies in order to function. The requirementsare as follows: SDL2, SDL IMAGE and SDL TTF.

3.3.2 Testing Tools

In order to test performance of the video game developed, Initially third party tool wereconsidered, however that presented a number of issues such as possible inconsistenciesbetween the frame rate capturing tools and inability to find appropriate software for Waylanddue to its recency.

Due to the issues mentioned, the game itself was developed to have benchmarking capa-bilities. This way it would remain consistent among different display server protocols. Themethod of capturing the frame rate in the video game is described in more detail in section4.3.3.

In order to present the data captured in a graphical and easily readable way, a data visual-ization package was used. Ggplot2 is a plotting system for R - a programming language forstatistical computing and graphics. The ggplot2 package, created by Hadley Wickham, offersa powerful graphics language for creating elegant and complex plots[53].

20

4 Development

This section talks about the steps that were taken and the development models used duringthe development of the software required for this dissertation.

4.1 Development Model

Both the Wayland compositing window manager and the SDL2 video game were developedusing the waterfall model, also called the linear-sequential life cycle model, one of the projectslater turned to using the spiral model. The Gantt chart in Figure 4 describes the initial workplan. Two out of three objectives were to develop software. Each of those two objectiveswere treated as separate projects with their own separate waterfall method phases. TheWaterfall model is known to be simple and to work well on smaller projects. Since the projectrequired two separate, small to mid-sized applications, the waterfall model seemed to fit therequirements well.

The waterfall Model illustrates the software development process in a linear sequential flow.This means that any phase in the development process begins only if the previous phaseis complete. In the waterfall model, the phases do not overlap. The advantages of waterfallmethod are as follows: it allows for departmentalization and control. A schedule can be setfor each stage of development which helps to keep track of progress focus on finishing thestages on time. Other advantages include: ease of use, ease of management due to rigidityof the model, clearly defined stages, easy to arrange tasks and measure results[54].

The disadvantages of waterfall model are that it does not allow much reflection or revision.There is a high amount of risk when planning because it is difficult to amend completedstages of development, therefore this method is advisable for smaller projects. Additionally,waterfall method works poorly with ongoing projects or projects that are expected to changethroughout development. However the disadvantages of the waterfall model for the cross-platform video game project required for this dissertation can be virtually completely avoideddue to the type of software developed - relatively small, thought out project with a clear endgoal. The compositing window manager however, required a lot of prototyping due to issueswith development, that are discussed in section 4.2.3, and therefore moved to a spiral modellater in development.

Spiral Model is a combination of a waterfall model and iterative model. Each phase inspiral model begins with a design goal and ends with the client reviewing the progress. Thespiral model was first mentioned by Barry Boehm in his 1986 paper[55]. The project startswith a small set of requirement and goes through each development phase for those set ofrequirements. Functionality is added for each additional requirement in ever-increasing spiralsuntil the application is developed. The spiral model is useful when creation of a prototype isapplicable, when requirements are unclear or complex or when the project’s requirementsmay change at any time.

The advantages of a spiral model include the ability to include changes and functionality atlater stages of development, easier cost estimation due to prototype building being donein small fragments and continuous development helping with risk management. Theseadvantages proved useful in later stages of development as these stages required a lot ofexperimental changes and prototypes.

The spiral model is not recommended for smaller projects as it is complicated and expensive,the projects using this model depend on accurate risk analysis. Additionally, it is difficult

21

to estimate development time using this model because the number of phases required tocomplete the project is unknown during development. Despite these disadvantages, thespiral method allows for a lot of prototyping which was necessary for the development of thecompositing windows manager.

4.2 Wayward (Wayland Compositor)

This section details the development process for the compositing window manager requiredfor this project and further describes the wlroots library and the Wayland protocol.

The Wayland protocol is an asynchronous object oriented protocol. All requests are methodinvocations on some object. The requests include an object ID that uniquely identifies anobject on the server. Each object implements an interface and the requests include an opcodethat identifies which method in the interface to invoke.[56]

The server manages the resources like the keyboard or a surface to draw on. The protocol ismessage-based. A message sent by a client to the server is called request. A message fromthe server to a client is called event. A message has a number of arguments.

Some of the resources are global, these resources are called global objects or simplyglobals. Globals are things such as wl output, which are displays connected to a GPU. Otherresources, for example wl surface,require the client to request the server to allocate newresources when needed. Negotiating for new resources is done through the API of someglobal resource.

The Wayland client gets started by obtaining a reference to the core global object - wl display.This establishes a connection to the Wayland server. The wl display is responsible forproviding the wl registry which enumerates the global objects that are available to all clients.When a client creates a registry object, the registry object will emit a global event for eachglobal currently in the registry.

In order to create a surface to display pixels with the Wayland protocol:

1. Obtain wl display and use it to obtain wl registry.

2. Scan the registry for globals and acquire a wl compositor and a wl shm pool.

3. Use wl compositor interface to create a wl surface.

4. Use wl shell to describe the surface’s role.

5. Use wl shm to allocate shared memory to store pixels in.

6. Draw into shared memory buffers.

7. Attach shared memory buffers to the wl surface.[57]

The wl compositor is in charge of combining contents of multiple surfaces into one displayableoutput and creating a wl surface. The wl surface is a rectangular area that is displayed onthe screen. It has a location,size and pixel contents for the compositor to render. By default,a surface does not have a role, which means that the compositor does not know where, whenor how to present it. The role is the purpose of a wl surface. Roles of a surface can rangefrom a cursor for a pointer to a shell surface. Shell surfaces are implemented by serversthat provide desktop-style user interfaces. There are two primary ways of creating a bufferthat the compositor can use: EGL and shared memory. EGL uses an OpenGL context that

22

renders directly on the GPU with minimal compositor involvement, and shared memory viawl shm - global object that provides support for shared memory.[56][57]

4.2.1 Versions of software used

At the time of testing, the versions of software used were as follows:

• Wlroots version: 0.4.1.r26.g2baad6eb-1.

• Meson version: 0.49.2-2.

• Ninja version: 1.9.0-1.

• Linux Kernel version: 5.0.9-arch1-1-ARCH

4.2.2 Wlroots Set-up

To be able to compile the wlroots project, a meson.build file is required in order to specifythe project’s compiler arguments and dependencies. Additionally, wlroots requires scannedWayland protocols using the wayland-scanner which takes in an XML file describing a Waylandprotocol and outputs a C header file that can be used in wlroots. This project required theuse of the xdg shell protocol which describes application windows.

4.2.3 Creating the Compositor

This implementation of a Wayland compositor, which is named and occasionally will bereferred to as ’Wayward’, is based on a demonstration Wayland compositor ’Wayland McWay-face’[58] accompanied by a tutorial series of blog posts written by Drew DeVault[59]. However,since Wlroots is currently still in development and is constantly changing, the blog postsmentioned are out of date and therefore a more updated version of a Wlroots compositorcalled ’TinyWL’[60] had to be used, which boasts of being the ”minimum viable product”Wayland compositor.

The project started out by with defining a structure, also called a struct for short, that wouldhold the compositor’s state. The structure holds references to the display, backend andthe event loop, which is a crucial part of the compositor, it dispatches signals across theapplication, gets notified when data is available on various file descriptors, etc.

The backend is a wlroots interface which is responsible for abstracting the low level inputand output implementations from the user. Each backend can generate zero or more inputdevices and zero or more output devices. According to Drew DeVault’s blog post on creatinga Wayland compositor[59], There are various backends with various purposes:

• The ’drm’ backend utilises the Linux DRM subsystem to render directly to your physicaldisplays.

• The ’libinput’ backend utilizes libinput to enumerate and control physical input devices.

• The ’wayland’ backend creates “outputs” as windows on another running Waylandcompositors, allowing you to nest compositors. Useful for debugging.

• The x11 backend is similar to the Wayland backend, but opens an x11 window on anx11 server rather than a Wayland window on a Wayland server.

Another possible backend is the ’multi’ backend. It can initialise several backends at once.Wlroots has a function that selects the most appropriate backend for a compositor. This

23

Figure 5: Running ’weston-info’ on Wayward, listing all global objects

function was used for this project, meaning that when the compositor is run from a TTY, it isgoing to use the DRM backend.

In order to render something, the compositor has to know about the output to render to. Thebackend provides wl signal that notifies the compositor when a new output is available.

The next step is to set the output mode of the output that is going to be rendered to. Outputmodes specify a size and refresh rate supported by the output.

Lastly, in order to be able to render anything, a reference to the wl renderer is required. It canbe obtained from the backend. At this point the compositor is able to render, for example, asolid colour to a screen.[59]

Now that the we are able to render something to the screen, it is time to set up a server forapplications to be able to attach Wayland clients to the compositor. Setting up a server is asimple process, involving a single call to a wlroots function called wl display add socket auto.To check if the server has been set up properly it is possible to use Weston’s reference clientsto connect to the compositor’s server and list its global objects.

Figure 5 lists all the global object currently set up in Wayward, these are just examples, theywill be removed in the future. Global objects provide interfaces for clients to interact with thecompositor’s server.[61]

In order to have clients render to the screen, we need to create a compositor global object.The wl compositor global is used by clients to allocate wl surfaces to which they attachwl buffers. The surfaces are used for sharing buffers of pixels with compositors and donot carry an implicit role, such as ”application window” or ”panel”.[62] In Wayland, shellsprovide surfaces with a role, these roles can range from right-click menus to applicationwindows. Shells generally take a wl surface resource, assign it a role and return a handlewith shell-specific interfaces for manipulating it[63]. The shell that this compositor implementsis the xdg-shell. This type of shell provides desktop-style user interfaces and is currentlythe only shell whose protocol is considered stable. The xdg-shell tries to encapsulate everyfeature of a typical graphical desktop session in a single protol.[62] Figure 6 shows a client

24

(LibreOffice) running on the compositor using the xdg-shell.

Next step is input handling. Wlroots provides a very hands-off design for input in order tosupport many use-cases. It can handle input for desktop computers, phones, multiple micebound to a single cursor, on-screen keyboards etc. Wlroots backend provides an event forhandling input, which is called with a reference to an input device each time a new inputdevice appears on the backend, for example plugging in a keyboard or mouse into a computer.The input device can be one of five types:

• KEYBOARD

• POINTER

• TOUCH

• TABLET TOOL

• TABLET PAD

The wlroots keyboard struct provides its own events, such as key and keymap. These eventsdo not automatically propagate to any Wayland clients, communicating these events to clientsis the responsibility of the developer. Wayland handles input using the top-level resourcecalled wl seat. A seat is a group of keyboards, pointer and touch devices. A seat typicallyhas a pointer and maintains a keyboard focus and a pointer focus.

While the compositor originally was supposed to have keyboard input support it is not goingto, due to time constraints for this project and issues with input capturing in pure Waylandenvironments. After a number of attempts at implementing keyboard handling, the researcherwas not able to achieve the task, however it appears that wlroots has issues handling inputin its current state. Even the developer of wlroots posted on an online forum, stating ”Inputmethods are hit and miss - they work with Xwayland, but not with native Wayland applications.But rest assured that someone hacking on Wayland has a vested interest in getting this towork is looking into it.”[64].

25

Figure 6: Running LibreOffice on Wayward

4.3 SDL2 Game

This section talks about the set-up, development and the porting process for the cross-platformvideo game required for this project. This game was made as part of a university module’scoursework, due to this reason it saw changes in development environments throughout theproject.

4.3.1 Versions of Software used

The software used were of the following versions at the time of development:

• Visual Studio Community 2017: 15.9.11

• Visual Studio Code: 1.33.1-1

• SDL2: 2.0.9-1

• SDL2 IMAGE: 2.0.4-2

• SDL2 TTF: 2.0.15-1

• CMake: 3.14.3-1

• GNU Make: 4.2.1-3

• Clang: 8.0.0-3

4.3.2 Development Environment

Initial development environment for the video game was using Visual studio on Windows10. Development later on the project moved to using Visual Studio Code on Arch Linux with

26

CMake and GNU Make, the process of moving from Windows 10 to Arch Linux is describedin more detail in section 4.4.1.

Setting up these dependencies on Windows 10 involved downloading the required packagesfrom their respective websites and manually specifying the header files and library files inVisual Studio.

Setting up on Arch Linux required installing appropriate packages from the package repositoryand a CMake file in order to specify the compiler flags, include directories and link SDL2libraries. After creating a CMakeLists.txt file, everything had to be compiled with GNU Make.

4.3.3 Creating the Game

The Game developed is called and will be occasionally referred to as ”Daunting Dungeon”and it is a 2D sprite-based video game involving force-based physics in order for the gameto be more computationally intensive and therefore possibly have more varying frame ratesbetween different compositors. Since the implementation of the game is not relevant to theproject, this section will not go into great detail on how Daunting Dungeon was developed.

The game involves the usual components of a 2D video game: the rendering, keyboardinput, interactive elements. It is developed using C++ for more efficient memory-managementwhich is useful in video game development. Figure 8 shows the game developed. It is afairly minimal product that does not include complicated game mechanics or a lot of contentas a result of the time constraints for this project. Because SDL2 is a development libraryand not a game engine and/or a development platform, such as Unity[65], most of thedevelopment time was spent creating the game engine, opposed to making visual aspects ofthe game. Creating the game engine included collision detection and resolution for gameobjects, texture rendering and input handling. Figure 7 shows the class diagram for the videogame developed.

Figure 7: Class Diagram of Daunting Dungeon, Automatically Generated using Visual StudioClass Designer[66]

The part of development that is most relevant to this project is the frame rate counting.Whenever the game is started, the frame rate counting begins and it is calculated by countingthe number of iterations of the game loop i.e. how many times the game managed to calculatethe physics, handle game events and render the changes to screen. The frame rate for each

27

Figure 8: Daunting Dungeon: the video game developed, running on I3 window manager(X11). Game assets by HorusKDI[67] and 0x72[68]

second is stored in an array of size 60, for each second in a minute respectively. The testis repeated 5 times and the result for each second is averaged, therefore the total run timeof the test is 5 minutes. This low mount of repetition was chosen because longer run timeshad an adverse effect on the results due to the machine, that the tests were run on, startingto overheat during longer test runs as SDL2, without limiting the frame rate, would end uputilising virtually all CPU time in order to output as many frames as possible. Figure 9 showsthe class diagram used for testing the frame rate.

28

Figure 9: FPS Counting Class, Diagram Automatically Generated using Visual Studio ClassDesigner[66]

4.4 Porting

This section describes the porting process of the video game developed. Since the de-velopment library used supports Wayland natively, the porting process in this case was asimple task. Porting an application that does not support Wayland is a more complicatedprocess, which involves change backend-specific code in the application to Wayland’s APIcalls. Thankfully there are quite a few development toolkits that support Wayland and allowfor easy porting. Examples of such toolkits are: Qt 5 - a cross-platform application frameworkthat is used for developing application software that can be run on various software andhardware platforms, GTK+ - a multi-platform toolkit for creating graphical user interfaces, EFL- a set of graphics libraries that grew out of the development of Enlightenment, a windowmanager and Wayland compositor[69].

4.4.1 Porting to X11

Porting the video game from Windows to Linux was a straightforward process due to SDL2being cross-platform development library. The main issue was setting up a CMakeLists.txt filein order to compile the project due to not having prior experience doing so. Another issuewas compiler differences between Microsoft C++ compiler and Clang, which have causeda number issues when trying to run the video game. As mentioned in section 2.2.6, C++ is

29

a compiled language, meaning that its implementation is in the compiler used, therefore inorder to move the video from Microsoft C++ compiler to Clang, it was a matter of fixing errorsthat arose due to compiler differences.

4.4.2 Porting to Wayland

Once the game ran on X11, launching the game on Wayland was a trivial task because SDL2supports Wayland by default. The only difference from running it on X11 was that a Linuxenvironment variable ”SDL VIDEODRIVER” had to be set to ”wayland”. On UNIX-basedsystems, environment variables are simply variables that describe the system’s properties[70].

30

5 Testing

This section describes the process of evaluating the game’s performance on different windowmanagers and compositors for both X11 and Wayland. All window managers and composit-ing window managers will be referred to as compositors in this section for the sake andconvenience. Additionally, this section provides graphs of the testing results.

5.1 Compositor Versions

• I3: 4.16.1-1

• KWin: 5.15.4-1

• Mutter:3.32.1-1

• Sway: 1.0-8

• Weston: 5.0.90

5.2 Measuring Performance on X11

The X11 compositors used benchmarked are I3, KWin and Mutter.

I3 is a tiling window manager, written in C and designed for X11. Tiling window managersorganise the screen into mutually non-overlapping frames, as opposed to the more popularapproach of coordinate-based stacking of overlapping objects, such as on Windows operatingsystems, that tries to fully emulate the desktop metaphor. Being a window manager, i3 is avery lightweight environment, on idle taking up only around 300-400Mb of RAM. I3 focuseson well written, documented code, that encourages user contribution[71].

KWin is a composited Window Manager for Xorg windowing systems (Wayland, X11), it is partof the KDE desktop environment. KWin is currently in the process of becoming a Waylandcompositor. KWin is designed to go out of the way; users should not notice that they use awindow manager at all. Nevertheless KWin provides a steep learning curve for advancedfeatures, which are available, if they do not conflict with the primary mission[15]. The reasonKWin is not used as a Wayland compositor in these tests is due to issues with disablingXwayland on the Wayland backend of KWin.

Mutter is a Wayland display server and X11 window manager and compositor library.Itimplements the compositor side of the Wayland core protocol as well as various protocolextensions. It also has functionality related to running X11 applications using Xwayland. Itcontains functionality related to, among other things, window management, window composit-ing, focus tracking, workspace management, keybindings and monitor configuration. Mutteris the default compositor for the GNOME desktop environment[14] and can be run as either aWayland or X11 compositor.

Figure 10 shows the test results for the i3 window manager. At around the 30 second mark theframe rate drops by around 10 FPS, this seems to be the OS specific issue since it was notpossible to recreate the same result on a different operating system. The most likely reasonfor this behaviour is the operating system’s CPU frequency governor settings, however thebehaviour is consistent therefore it does not interfere with the test results. This test was runwith a default i3 configuration. I3 was launched by simply selecting it in the display manageron system launch.

31

Figure 11 shows the results for KWin on X11. The most obvious difference is that KWin takessome time to start up, compared to i3, however once the game reaches its top frame rate onKWin, it has slightly better performance than i3 with a higher average frame rate. This testwas run with a default KWin configuration. In order to avoid running the whole KDE desktopenvironment, KWin had to be launched from the TTY with the following command: ’kwin x11—replace’.

Figure 12 shows the results for Mutter on X11. After multiple failed attempts to run Mutterwithout the GNOME desktop environment, the compositor was run by selecting the ”Gnomeon Xorg” desktop environment from the display manager. This issue should not interfere withthe results as long as the Mutter test on Wayland is launched the same way.

Figure 10: Test Frame Rate on I3(X11), Average FPS: 317.1

32

Figure 11: Test Frame Rate on KWin(X11), Average FPS: 318.47

Figure 12: Test Frame Rate on Mutter(X11), Average FPS: 309.413

33

5.3 Measuring Performance on Wayland

The Wayland compositors benchmarked are Sway, Wayward, Weston and Mutter.

Sway is a tiling Wayland compositor and a drop-in replacement for the i3 window manager forX11. The compositor was developed by DrewDeVault, the creator of wlroots.and other volun-teers. Sway is arguably the most popular and most actively developed Wayland compositorat the moment, recently having its first stable release version 1.0 and being rewritten usingwlroots[72].

Figure 13: Test Frame Rate on Sway(Wayland), Average FPS: 323.77

Wayward is the compositor specifically developed for this project. It is not a complete com-positor and therefore will not be considered in the compositor comparisons in section 6. Dueto the lack of certain features, even launching the video game on it was not a straightforwardtask. In order to run the game, the operating system’s login manager, also called a displaymanager, had to be disabled, which meant that no graphical environment would be launchedon system start-up. Because this compositor does not have keyboard handling, a script wasrequired that would launch the compositor from a TTY, wait until it has fully launched, thenchange the current working directory to the game’s folder and launch the game as a Waylandapplication.

Weston is the reference implementation of a Wayland compositor, as well as a useful en-vironment in and of itself. The core focus of Weston is correctness and reliability. Westonaims to be lean and fast, and predictable[33]. Additionally, Weston provides a number ofutilities that are useful for Wayland compositors, such as ”weston-info”, that can list a Waylandcompositor’s global objects.

Figure 13 shows the results for Sway. Running Daunting Dungeon on Sway was possiblythe simplest process from all Wayland compositor as it was possible to simply select Sway

34

Figure 14: Test Frame Rate on Wayward(Wayland), Average FPS: 60

from the display manager to launch it and it already had keyboard shortcuts for launching aterminal, in this case, Termite[73] terminal emulator was used to launch the game developed.This test was run with all default Sway values except the ’xwayland disable’ setting turned onin order to disable the xWayland support and get the full performance from Wayland.

Figure 14 shows the test result for Wayward. As seen from the frame rate achieved, thecompositor failed to render the game properly. While not enough research was done, due totime constraints, to determine the exact reason for this, it appears that the frame rate waslocked to the monitor’s refresh rate.

Figure 15 shows the test result for Weston. The test was run with default Weston configuration.When run from a TTY, Weston uses the DRM backend which means that it will run withoutany underlying windowing system and render the frames directly to screen[74].

Figure 16 shows the results for Mutter running on Wayland. In order to be able to run thiscompositor, the ”Gnome on Wayland” desktop environment had to be selected from thedisplay manager.

35

Figure 15: Test Frame Rate on Weston(Wayland), Average FPS: 329

Figure 16: Test Frame Rate on Mutter(Wayland), Average FPS: 319.283

36

5.4 Measuring Performance on Windows

Even thought this project is not particularly concerned with the game’s performance onWindows 10, it can be useful to see what results were achieved on it to put things intoperspective. The same test was performed as with other window managers, however theresearcher was not able to disable the discrete GPU for this operating system and thereforethis test did not have equal conditions as the ones done on Linux. While this single test doesnot provide enough data to draw any meaningful conclusions other than that the game portingprocess from Windows 10 to Linux was successful, the fact that the frame rate on Windows10 is significantly lower than on Linux might suggest that the graphics stack on the MicrosoftWindow’s Desktop Window Manager is less efficient than on Linux or that Windows 10 hasworse performance than Linux when comparing applications that are optimised for bothoperating systems. Another reason for such performance difference might be the compilersused to compile both versions of the game. On Windows 10 Microsoft C++ compiler wasused and on Arch Linux Clang was used. Since C++ is a compiled language, which meansthat the implementation of C++ is the compiler itself, the compiler used can have an impacton the application’s performance.

Figure 17: Test Frame Rate on Windows 10, Average FPS: 181.71

5.5 Other Discrepancies Between Protocols

While it is difficult to measure and demonstrate, Wayland compositors appeared to begenerally faster and ”smoother” as it was not possible to observe any screen tearing - a visualartefact where a display device shows information from multiple frames at the same time.This effect was commonly observed on X11, in applications such as web browsers or videoplayback. This is not surprising as Wayland was developed with removing screen tearing in

37

mind. No matter the system load, Wayland compositors should be tear-free because Waylandkeeps track of what order the frames need to be displayed in and follows the philosophy of“Every frame is perfect”[75].

From the amount of testing done, there were not any other meaningful differences observedbetween the display server protocols.

38

6 Evaluation

This section tries to make more comparisons of the two display server protocols under testand further analyse the test results gathered during this project.

6.1 Protocol Performance Comparison

Figure 18 shows the average frame rate for all tested compositors, sorted in descending orderof average FPS. From these results it is evident that the Wayland compositors have performedslightly better than their X11 counterparts. Special attention should be paid to Sway versus i3and both backends of Mutter as the Wayland versions were specifically designed to replacethe X11 ones.

Figure 18: Graph of all tested compositors’ FPS

Figure 19 shows the frame rate throughout the test for both Sway and I3. Both compositorshave very similar functionality and design goals, Sway has achieved around a 5 FPS increasein performance. According to Figure 19 Sway managed to not only achieve a higher framerate but also have a more stable frame rate as I3’s frame rate appears to fluctuate more.

The Wayland version of Mutter achieved a 10 FPS increase. However, judging by Figure 20the Wayland version would drop down in frames at a later time than X11 but then achieve asimilar frame rate. Additionally, Mutter’s Wayland backend’s FPS appears to fluctuate lessthan the X11 backend, similar to i3 vs Sway’s results.

While Weston and Kwin do not share similarities, like the other compositors tested, they bothperformed the best in their protocol types. Figure 21 shows the comparison between KWinand Weston. Weston performed the best out of all tested compositors, achieving an average

39

frame rate of 329 FPS. KWin was the best performing X11 compositor with an average framerate of 319.283 FPS. Just like with other compositors, the Wayland compositor seems to havea more stable FPS than the X11 one.

Figure 19: Graph Comparison of Test Frame Rate on Sway and I3

40

Figure 20: Graph Comparison of Test Frame Rate on Mutter Wayland and X11 backends

Figure 21: Graph Comparison of Test Frame Rate on KWin and Weston

41

7 Conclusion

This section draws conclusions from the test results, reflects on the project’s achievementsand shortcomings, discusses possible future work for this project.

7.1 Outcome

All tested Wayland compositors have achieved a slightly better frame rate than the X11 ones.This can be attributed to the simplified graphics stack that can be seen in Figure 3. Sincein Wayland the compositor is the display server, it allows for more efficient rendering andtherefore more performance. According to the tests done in this project, that increase canbe from 5 to 10 FPS. In addition to that, rendering was also improved by eliminating screentearing.

While Wayland outperformed X11 in raw performance, it is still a new protocol that lacks a lotof the functionality of X11. Wayland is going to need a lot more development to compete withX11 as the most used display server protocol.

The results achieved in this dissertation may not be conclusive enough to declare Waylandas superior to X11 but they do show that Wayland is a promising project and if it keepsevolving at the rate it is now, this new display server protocol might just overtake the almostthree-decade-old protocol used in Linux currently.

7.2 Reflection on Project

The project did not end up adhering to the Gantt chart in the Planning section due to issuesthroughout the project and change of requirements. During development, an additionalobjective was added, which was to benchmark the video game developed on a number ofX11 and Wayland compositors as test results from a single Wayland compositor that wasdeveloped for this dissertation would not be sufficient to be able to compare the performanceof both display server protocols and draw meaningful conclusions.

The researcher failed to implement a fully functional Wayland compositing window manager.This failure can be mostly be attributed to not conducting enough research before setting theaims and objectives for the project. Creating a compositor is certainly not an easy task andexpecting to create a Wayland compositing window manager that would incorporate all thebasic functionality of a typical compositor with the time constraints of this project was not afeasible task. Developing a compositor can take a long time especially for a single personwith no prior experience of developing window managers. As a result of this, the objective ofbenchmarking the video game developed using the compositor developed was not successfulas well, since Wayward failed to achieve a frame rate higher than 60FPS. It is not entirelyclear why the frame rate was capped at 60, but it is likely due to the compositor trying tomatch the refresh rate of the monitor used.

Creating a cross platform game was a success. While the game did not include a lot of visualelements and complicated game mechanics, it was written with the game engine, that wasbuilt throughout this project, and had excellent cross-platform performance. Curiously, thegame’s performance was substantially better on Arch Linux than Windows 10. This can havea number of causes, which were discussed in section 5.4

The task of benchmarking Daunting Dungeon on an already created compositors wasachieved well, since the tools for benchmarking were also created specifically for this project.

42

The result gathering process was handled completely automatically, with the game itselfwriting the frame rate values to a CSV file after completing the benchmark test. Followingthat, the gathered results were plotted using a professional plotting tool called ggplot2 whichhandled all gathered datasets equally and provided precise graphs.

Overall, there were issues with accomplishing all the set out goals, however the tests them-selves were performed successfully. The main issues while developing the compositor werethat the documentation was scarce. Main source of documentation was the header files inwlroots’ library code as there is no official documentation at the time of writing this dissertation.Additionally, the whole project required considerably more research than anticipated since thisdissertation required two separate and different software applications to be developed and theuse of additional software on different platforms such as different development environments,compilers, benchmarking, plotting and build tools.

Main mistakes that were made and should have been avoided were as follows: too littleresearch before deciding on the aims and objectives of the project. The topics of the Linuxgraphics stack, display server protocols and rendering performance are complicated onesand require significant amounts of research on of those topics. Due to this mistake theproject aims and objectives were changing as more research was done, interrupting the workprocess and eventually leading to a failed objective of creating a working Wayland compositorin the span of a couple of months. While this particular objective was not essential to thewhole project’s success and the secondary task of understanding how Wayland works hasbeen achieved, the mistake of planning without enough research could have easily had amore detrimental impact on the whole project if, for example, not enough research wouldhave been done on the cross-platform game development library and an unfitting one hadbeen chosen. Another mistake of this dissertation was the scope set out for it. Even withoutsufficient research, the whole project was too ambitious. Developing a compositing windowsmanager, a cross-platform video game and a way to benchmark the game was too much fora dissertation of this scope. The researcher failed to account for other university modulesduring the academic year and miscalculated the amount of time that could be dedicated tothis project. One possible solution to this issue could have been to focus on the developmentof a more comprehensive benchmarking tool and not creating a new compositing windowmanager. This would have lowered the amount of work that had to be done for the project andwould allow the researcher to dedicate more resources to other aspects of the dissertation.

The project was a valuable learning experience that has provided insight into a numberof development areas such as low-level programming with C and C++, project compilingand differences between compilers, understanding of different build systems and tools, theprocess of developing a cross-platform application. Apart from development, this dissertationhas provided experience with doing research, planning and scheduling substantial projectsthat include a lot of different requirements, visualising data by utilising a graphics visualisationpackage and a statistical programming language R.

7.3 Future Work

Possible future work on this domain could be to expand on this test scenario and implementa more comprehensive and complete test. Successfully implementing a Wayland compositorand documenting the development process would enable people to use the compositor asa basis for their own work or provide an easier option for learning how to develop Waylandcompositors. In addition to creating a Wayland compositor, one could develop an X11compositing window manager and compare the development process and hopefully highlight

43

more differences between the two display server protocols. Also creating a more complicatedand predictable benchmark that would test the compositors under more varying levels ofsystem load would provide more data and therefore a more precise comparison of the twoprotocols.

Writing documentation for Wayland and wlroots would enable more people to contributeto these projects and hopefully speed up their development. Additionally, contributing tothese project is also a good option to speed up the development and adoption of Wayland.In addition to developing the display server protocol, to be able to utilise pure Wayland,applications have to be developed for Wayland or have Wayland ports. More options forWayland would enable more people to switch to the new protocol and in turn incentivisedevelopers to support it.

44

Appendices

Software Developed

Daunting Dungeon - https://github.com/SerCoach1/DauntingDungeonWayward - https://github.com/SerCoach1/Wayward

45

Glossary

Assembly The assembler language is the symbolic programming language that lies closestto the machine language in form and content[76]. 15

Bitmap An image file format that can be used to create and store computer graphics[77]. 10

Compiler A software program that transforms high-level source code that is written by adeveloper in a high-level programming language into a low level object code[78]. 15, 17

Direct3D an API created by Microsoft that is used to render three-dimensional objects[79].16

DRM A device-independent kernel-level device driver that provides support for the DirectRendering Infrastructure (DRI)[80]. 23, 24, 35

EGL An interface that handles graphics context management, surface/buffer binding, andrendering synchronization and enables high-performance, accelerated, mixed-mode 2Dand 3D rendering[81]. 22

Emacs A family of text editors which are described as extensible, customizable, self-documenting, real-time display editors[82]. 9

FreeBSD An operating system used to power modern servers, desktops, and embeddedplatforms[83]. 15

Interprocess Communication (IPC) Mechanism for facilitating communications and datasharing between applications[84]. 9

Kernel The kernel is a program that constitutes the central core of a computer operatingsystem. It has complete control over everything that occurs in the system.[85]. 5, 11,14, 17, 23, 46

Libinput An input device driver for Wayland compositors and X.org window system[86]. 23

LibreOffice Free and open source office suite[87]. 25

Linux Linux is a free and open-source software operating system based on the Linux kernel,first released on September 17, 1991 by Linus Torvalds.[88]. 1, 5, 8, 14, 15, 16, 17, 19,20, 23, 27, 29, 30, 37, 42, 43

Opcode (computing) A mnemonic used to refer to a microprocessor instruction in assemblylanguage.[89]. 22

OpenGL 2D and 3D graphics API[90]. 16, 17, 22

Shader a program specifically made to run on a GPU[42]. 17

Sprite A bitmap graphic that is designed to be part of a larger scene. It can either be a staticimage or an animated graphic[91]. 27

TrueType A font standard developed by Apple and Microsoft[92]. 17

46

UNIX Stable, multi-user, multi-tasking operating system for servers, desktops and laptops[93].30

Acronyms

2D Two-Dimensional. 27

API Application Programming Interface. 17, 22, 29, 46

CSV Comma-Separated Values. 43

FAQ Frequently Asked Questions. 15

FPS Frames Per Second. 4, 29, 31, 32, 33, 34, 35, 36, 37, 39, 40, 42

GPU Graphics Processing Unit. 15, 19, 22, 23, 37, 46

GUI Graphical User Interface. 4, 8, 9

IDE Integrated Development Environment. 17, 19

OS Operating System. 31

SDL2 Simple DirectMedia Layer. 6, 16, 17, 21, 27, 28, 29, 30

SFML Simple and Fast Multimedia Library. 17

TTY TeleType Terminal. 24, 32, 34, 35

UI User Interface. 16

XML Extensible Markup Language. 23

47

References[1] freedesktop.org. Wayland. https://wayland.freedesktop.org/.

[2] Why Wayland anyway? https://blogs.gnome.org/mclasen/2016/03/04/why-

wayland-anyway/. 2016.

[3] Drew DeVault. Wlroots. https://github.com/swaywm/wlroots. 2019.

[4] Athanasios Tasoglou. Arch Linux Install Guide – Desktop Environment Installation.http://turlucode.com/arch-linux-install-guide-step-2-desktop-environment-

installation/. 2016.

[5] PCMag Encyclopedia. Definition of: window manager. https://www.pcmag.com/encyclopedia/term/54598/window-manager. 2018.

[6] Allen Kent and James G. Williams. Encyclopedia of Microcomputers. CRC Press; 1edition (11 Oct. 1996).

[7] Howling Pixel. Compositing window manager. https://howlingpixel.com/i-en/Compositing_window_manager. 2019.

[8] Scott Hanggie et al. Compositing desktop window manager. https://patentimages.storage.googleapis.com/5c/3a/05/16a4207ae166e2/US7839419.pdf. 2010.

[9] R. D. Davis. PERQ Workstations. http://bitsavers.informatik.uni-stuttgart.de/pdf/perq/RD_Davis/Davis-PERQ_Workstations_Nov03.pdf. 2003.

[10] Wikiwand. Stacking window manager. https://www.wikiwand.com/en/Stacking_window_manager. 2018.

[11] Omega Elowar. Amiga RKM Libraries Manual. http://amigadev.elowar.com/read/ADCD_2.1/Libraries_Manual_guide/node011C.html. 1993.

[12] arsTECHNICA. Mac OS X 10.4 Tiger. https://arstechnica.com/gadgets/2005/04/macosx-10-4/13/. 2005.

[13] Microsoft. The Desktop Window Manager. https://docs.microsoft.com/en-us/windows/desktop/learnwin32/the-desktop-window-manager. 2018.

[14] Koen Vervloesem. Mutter: a window manager for GNOME 3. https://lwn.net/Articles/344734/. 2009.

[15] KDE. KWin. https://userbase.kde.org/KWin. 2019.

[16] GNU/Linux Discussion. X.Org alternatives? MicroXWin, Wayland, Y, DFB, Xynth,Fresco, etc.. https://bbs.archlinux.org/viewtopic.php?id=87281. 2009.

[17] Philip Taylor. The Y Window System. https://www.academia.edu/10888233/The_Y_Window_System. 1992.

[18] Derek Foreman. [ANNOUNCE] wayland 1.16.0. https://lists.freedesktop.org/archives/wayland-devel/2018-August/039358.html. 2018.

[19] Mark Shuttleworth. Unity on Wayland. https : / / www . markshuttleworth . com /

archives/551. 2010.

[20] X.Org Foundation. X.Org. https://www.x.org/wiki/. 2019.

[21] Hans Peersman et al. X Window System. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.476.6648&rep=rep1&type=pdf.

[22] Simson Garfinkel. The Unix-Haters Handbook. IDG, 1994.

[23] Bill Bumgarner. Debian Mailing List. https://lists.debian.org/debian-user/1996/11/msg00637.html. 1996.

48

[24] Doug Kilpatrick, Wayne Salamon, and Chris Vance. Securing The X Window SystemWith SELinux. ftp://unix.hensa.ac.uk/sites/ftp.wiretapped.net/pub/security/operating - systems / selinux / papers / securing - the - x - window - system - with -

selinux.pdf. 2003.

[25] X.Org Foundation. X12. https://www.x.org/wiki/Development/X12/. 2017.

[26] Drew DeVault. Wayland misconceptions debunked. https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html. 2019.

[27] Hjdskes. Cage. https://github.com/Hjdskes/cage. 2019.

[28] X11 on Windows Machines. https://cc.jlab.org/windows/X11onWindows. 2010.

[29] https://www.xquartz.org/. 2016.

[30] Johannes Lundberg. Vote: making wayland=on default. https://lists.freebsd.org/pipermail/freebsd-ports/2017-December/111906.html. 2017.

[31] Dennis M. Ritchie. The Development of the C Language*. https://www.bell-labs.com/usr/dmr/www/chist.html. 2003.

[32] Ken Thompson. Users’ Reference to B. https : / / web . archive . org / web /

20150611114427/https://www.bell-labs.com/usr/dmr/www/kbman.pdf. 1972.

[33] Wayland-Project. Weston. https://github.com/wayland-project/weston. 2019.

[34] Michael Larabel. Purism Shares The Progress Made On Their Librem 5 SmartphoneFor The End Of 2018. https://www.phoronix.com/scan.php?page=news_item&px=Librem-5-EOY2018-Update. 2019.

[35] Meson Development Team. The Meson Build system. https://mesonbuild.com/.2019.

[36] Ninja. https://ninja-build.org/. 2019.

[37] Kitware. CMake. https://cmake.org/. 2019.

[38] Free Software Foundation. GNU Make. https://www.gnu.org/software/make/. 2016.

[39] Michael Larabel. SDL2 Wayland Now Supports XDG Shell’s XDG WM Base. https://www.phoronix.com/scan.php?page=news_item&px=SDL2-Wayland-XDG-WM-Base.2018.

[40] Sam Lantinga and Mattias Engdegard. SDL image 2.0. https://www.libsdl.org/projects/SDL_image/.

[41] Sam Lantinga. SDL ttf 2.0. https://www.libsdl.org/projects/SDL_ttf/.

[42] Unity. A Gentle Introduction to Shaders. https://unity3d.com/learn/tutorials/topics/graphics/gentle-introduction-shaders. 2019.

[43] Atlassian. What is Git. https://www.atlassian.com/git/tutorials/what-is-git.

[44] Klint Finley. What Exactly Is GitHub Anyway? https://techcrunch.com/2012/07/14/

what-exactly-is-github-anyway/. 2012.

[45] Microsoft. Visual Studio 2019. https://visualstudio.microsoft.com/vs/. 2019.

[46] Microsoft. Visual Studio Code. https://code.visualstudio.com/. 2019.

[47] Microsoft. Use any C++ Compiler with Visual Studio. https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/. 2017.

[48] TeamGantt. https://www.teamgantt.com/. 2019.

49

[49] Phoronix. Mozilla Now Ships Firefox Nightly Builds With Wayland Enabled. https://www.phoronix.com/scan.php?page=news_item&px=Firefox- Nightly- Ships-

Wayland. 2018.

[50] Phoronix. NVIDIA Working On An EGLStreams Back-End For KDE On Wayland. https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-KDE-KWin-EGLStreams-

POC. 2018.

[51] AMD. AMD Open Source Driver for Vulkan. https://github.com/GPUOpen-Drivers/AMDVLK. 2019.

[52] Asus. ASUS ZenBook UX303. https://www.asus.com/Laptops/ASUS- ZenBook-UX303UA/. 2014.

[53] ggplot2. https://ggplot2.tidyverse.org/.

[54] Try QA. What is Waterfall model Examples, advantages, disadvantages, when to useit? http://tryqa.com/what-is-waterfall-model-advantages-disadvantages-and-

when-to-use-it/. 2017.

[55] What is Spiral Model? When to Use? Advantages and Disadvantages. https://www.guru99.com/what-is-spiral-model-when-to-use-advantages-disadvantages.

html. 2019.

[56] Kristian Høgsberg. Wayland Documentation. https://wayland.freedesktop.org/docs/html/. 2012.

[57] Drew DeVault. An introduction to Wayland. https://drewdevault.com/2017/06/10/Introduction-to-Wayland.html. 2017.

[58] Drew DeVault. Wayland McWayface. https://github.com/ddevault/mcwayface.2018.

[59] Drew DeVault. Writing a Wayland Compositor, Part 1: Hello wlroots. https : / /

drewdevault.com/2018/02/17/Writing-a-Wayland-compositor-1.html. 2018.

[60] Drew DeVault. TinyWL. https://github.com/swaywm/wlroots/tree/master/tinywl.2019.

[61] Drew DeVault. Writing a Wayland Compositor, Part 2: Rigging up the server. https://drewdevault.com/2018/02/22/Writing-a-wayland-compositor-part-2.html.2018.

[62] Drew DeVault. Writing a Wayland Compositor, Part 3: Rendering a window. https://drewdevault.com/2018/02/28/Writing-a-wayland-compositor-part-3.html.2018.

[63] Drew DeVault. Writing a Wayland compositor with wlroots: shells. https : / /

drewdevault.com/2018/07/29/Wayland-shells.html. 2018.

[64] Reddit. Wayland misconceptions debunked. https://www.reddit.com/r/linux/comments/ap5k2j/wayland_misconceptions_debunked/. 2019.

[65] Unity Technologies. Unity. https://unity.com/. 2019.

[66] Microsoft. Design and view classes and types with Class Designer. https://docs.microsoft . com / en - us / visualstudio / ide / class - designer / designing - and -

viewing-classes-and-types?view=vs-2019. 2019.

[67] HorusKDI. Dungeon Tileset. https://opengameart.org/content/dungeon-tileset-4. 2018.

[68] 0x72. Dungeon Tileset 2. https://0x72.itch.io/dungeontileset-ii. 2019.

50

[69] Freedesktop. Toolkits. https://wayland.freedesktop.org/toolkits.html. 2019.

[70] Justin Ellingwood. How To Read and Set Environmental and Shell Variables on a LinuxVPS. https://www.digitalocean.com/community/tutorials/how-to-read-and-set-environmental-and-shell-variables-on-a-linux-vps. 2014.

[71] I3. https://i3wm.org/. 2019.

[72] It’s FOSS. Sway – Tiling Window Manager Specially Crafted for Wayland. https://itsfoss.com/sway-window-manager/. 2019.

[73] Arch Wiki. Termite. https://wiki.archlinux.org/index.php/Termite. 2019.

[74] Ubuntu Manuals. Weston-DRM. https://manpages.ubuntu.com/manpages/bionic/man7/weston-drm.7.html. 2019.

[75] Eric Griffith. The Wayland Situation: Facts About X vs. Wayland. https : / / www .

phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1. 2013.

[76] IBM. Assembler language. https : / / www . ibm . com / support / knowledgecenter /

SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/asmr102112.htm. 2014.

[77] Techopedia. Bitmap (BMP). https://www.techopedia.com/definition/792/bitmap-bmp. 2019.

[78] Techopedia. Compiler. https://www.techopedia.com/definition/3912/compiler.2019.

[79] Computer Hope. Direct3D. https://www.computerhope.com/jargon/d/direct3d.htm.2017.

[80] archive.today. index kernel/git/torvalds/linux.git. http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html. 2014.

[81] Khronos Group. EGL Overview. https://www.khronos.org/egl/. 2019.

[82] Free Software Foundation. GNU Emacs. https://www.gnu.org/software/emacs/.2018.

[83] The FreeBSD Project. https://www.freebsd.org/. 2019.

[84] Microsoft. Interprocess Communications. https://docs.microsoft.com/en- us/windows/desktop/ipc/interprocess-communications. 2018.

[85] The Linux Information Project. Kernel Definition. http://www.linfo.org/kernel.html.2004.

[86] Gentoo Wiki. Libinput. https://wiki.gentoo.org/wiki/Libinput. 2018.

[87] The Document Foundation. LibreOffice. urlhttps://www.libreoffice.org/. 2019.

[88] opensource.com. What is Linux? https://opensource.com/resources/linux.

[89] Your Dictionary. Opcode Definition. https://www.yourdictionary.com/opcode. 2019.

[90] Khronos Group. OpenGL Overview. https://www.opengl.org/about/. 2019.

[91] TechTerms. Sprite. https://techterms.com/definition/sprite. 2019.

[92] Microsoft. A brief history of TrueType. https : / / docs . microsoft . com / en - us /

typography/truetype/history. 2017.

[93] UNIX. UNIX Introduction. http://www.ee.surrey.ac.uk/Teaching/Unix/unixintro.html. 2000.

51