Fast GUI, Thinking aloud


17 posts
by DavidS » Sat Sep 28, 2013 1:32 pm
Has any one considered creating a Linux, BSD, or MINiX build that has a NanoX/Microwindows based GUI? I know that it is possible to compile a large number of programs to use NanoX+FLTK.

It seems a common complaint that the current combinations of X11+WM+Desktop Enviroment are slow. I do think that using something along the lines of a dynamic linked NanoX would solve this for applications that can be recompiled to use this. Also there are already a couple of Desktop Enviroments for NanoX. This could make for an interesting combination on the RPi. I know that NanoX is very quick, much quicker than X11 once you make sure to support acceleration in building.

Just thinking aloud, if someone does follow up with experimentation that would be great.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by Oakham » Sat Sep 28, 2013 1:51 pm
Well it has been ported to **-DOS so I do not see any reason why YOU could not give us a Pi ARMv6 Version, as you find the idea interesting:

http://code.google.com/p/nanox-microwin ... tk-for-dos

Anyway watch this video, towards the end it is stated that Wayland / Weston will be used instead of X

http://fora.tv/2013/09/21/raspberry_pi_shiny_new_toys

http://wayland.freedesktop.org/raspberrypi.html
Searching is easy, most questions have been asked before !
Posts: 366
Joined: Tue Aug 20, 2013 9:11 pm
by DavidS » Sat Sep 28, 2013 6:35 pm
@Oakham:
Yes that is just the most recent DOS stuff with NanoX. I first played with NanoX on DR-DOS sometime in the late 1990s, and it has gotten faster since then (even given the same HW). I did not play with NanoX on a *nix until a couple of years after playing with it on DR-DOS, and that was on MiNIX 2 (actually MiNIX-VMD, an extended version of MiNIX 2).

I am looking at the source code in Operating Systems: Design and Implementation 3/e as well as the updates to that to see if I think that there is the reasonable possibility of it being on the RPi in the near future.

And I know that there is an ARM port that is supposed to be working on the RPi though I can not find it.

Minix 3 is so much more capable than 2 was.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by OtherCrashOverride » Sun Sep 29, 2013 3:55 am
DavidS wrote:It seems a common complaint that the current combinations of X11+WM+Desktop Enviroment are slow.

The heart of the issue is that hardware is no longer designed like it was in the 80's. The concepts of sprites and bitblits have been replaced by compositing hardware (zero copy) and texture units.

http://www.microwindows.org/
There are two APIs implemented in the system, a Win32 API and an Xlib-like API.

Both APIs are obsolete today. A port would face the same challenges that current X11 does on the Raspberry PI. The bottleneck with current X11 is not the 'bloat'. Its the inability to utilize hardware acceleration on ARM devices that do not offer the legacy hardware that PC's do. Desktops are no longer 640x480 in 16 color.
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am
by OtherCrashOverride » Sun Sep 29, 2013 6:01 am
OtherCrashOverride wrote:Desktops are no longer 640x480 in 16 color.

Unless you are using Windows8 or iOS7! :lol:

16.7 million colors available and they use 4 of them. IBM3270 terminals were ahead of their time!
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am
by DavidS » Sun Sep 29, 2013 5:25 pm
OtherCrashOverride wrote:
DavidS wrote:It seems a common complaint that the current combinations of X11+WM+Desktop Enviroment are slow.

The heart of the issue is that hardware is no longer designed like it was in the 80's. The concepts of sprites and bitblits have been replaced by compositing hardware (zero copy) and texture units.

I was not aware that the X server is not using the video core stuff yet. Ok that could deffinitely make a big difference.

http://www.microwindows.org/
There are two APIs implemented in the system, a Win32 API and an Xlib-like API.

Both APIs are obsolete today.

Ok we had better stop using Linux/BSD/MiNIX + X then. And the windows 8 users better change OSes. Since you say we are all using obsolute APIs.

The XLib api is still heavily used by many things including most WMs. The Win32 API is still to this day the core of MS-Windows including Windows 8. Yes there are other wrappers built on top of these, though if you wish to us as few call layers between your self and X as possible to reduce latency by a few microseconds you are going to be calling Xlib. There is even an Xlib api in systems built around wayland (a graphics server that no one seems to like).

No mention of FLTK 1.1?
And here is an extended API included in NanoX. FLTK1.1 is quite usable, still many fltk apps out there, and the newer versions of FLTK are supersets of FLTK 1.1, unlike some APIs, so it is possable to port most FLTK based applications to NanoX with out too much work (so long as they do not have a thousand other dependancies).

A port would face the same challenges that current X11 does on the Raspberry PI. The bottleneck with current X11 is not the 'bloat'. Its the inability to utilize hardware acceleration on ARM devices that do not offer the legacy hardware that PC's do. Desktops are no longer 640x480 in 16 color.


As stated above I did not know that the X server in Raspbian does not use the VideoCore IV stuff that is available.

Ok look at the DOS verison (running at 16BPP = 65536 colors), or at the documents. The acceleration that Microwindows can use has nothing to do with the legacy PC video crap. And the Current DOS port and its applications are using a VESA 2 Frame Buffer, this has zero acceleration, though yet they are faster than the old version from the late 80s that used the VGA display (and there is acceleration available there [though minimal, and requiring some neat tricks that should not be alowed]).

Also I did not say that the bloat is the cause of the slow down. The X model is not that great for local applications, communication between the client and server takes significant overhead. The bloat is a seperate issue though just as important to correct. The two issues do cross over, as I said some of the waste in modern web browsers causes them to be slower than they should.

*****************************************************************************
As soon as I figure out what Linux distro I am going to be using I will begin looking at compiling MiNIX for the RPi. Once I have something that works in that area I will begin porting some of the user space MiNIX compononts so we can have something that is mostly POSIX. Then it will be time to begin to look at NanoX :) .
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by OtherCrashOverride » Mon Sep 30, 2013 2:45 am
DavidS wrote:Ok we had better stop using Linux/BSD/MiNIX + X then.

That is the current goal of industry leaders involved with *NIX, including the Raspberry Pi foundation. Most are going with Wayland/Weston. Some, like Ubuntu, are going with Mir, but everyone is moving away from X11 and Xlib.


DavidS wrote:The Win32 API is still to this day the core of MS-Windows including Windows 8.

Windows 8 deprecates (obsoletes) the Win32 API in favor of a new core called Windows Runtime aka WinRT (confusingly called the same as the tablet OS). WinRT does not wrap or sit atop Win32, it replaces it and is a requirement for new apps that are sold in the Windows 8 app store. Win32 is only provided for backwards compatibility.
http://www.infoq.com/news/2011/09/WinRT
WinRT is the new OS-level API layer. This is the new native API for Windows, it isn’t a new layer on top of Win32.


DavidS wrote:As soon as I figure out what Linux distro I am going to be using I will begin looking at compiling MiNIX for the RPi.

Minix is a microkernel versus Linux which is a monolithic kernel. Minix has higher overhead for operation due the nature of microkernels: a privilege change (context switch) is required for interacting with its subsystems, and it is far more dependent on IPC (message passing).

DavidS wrote:Once I have something that works in that area I will begin porting some of the user space MiNIX compononts so we can have something that is mostly POSIX. Then it will be time to begin to look at NanoX

I highly recommend this. Upon completion you will have better understanding of the issues involved and may even reach the same conclusions others have.
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am
by DavidS » Mon Sep 30, 2013 12:53 pm
OtherCrashOveride wrote:That is the current goal of industry leaders involved with *NIX, including the Raspberry Pi foundation. Most are going with Wayland/Weston. Some, like Ubuntu, are going with Mir, but everyone is moving away from X11 and Xlib.


And they still have to convince all of the programmers that prefer using the traditional means. Many of the GUI Libraries are still wrapped around X, and this is not like to change very quickly.

Windows 8 deprecates (obsoletes) the Win32 API in favor of a new core called Windows Runtime aka WinRT (confusingly called the same as the tablet OS). WinRT does not wrap or sit atop Win32, it replaces it and is a requirement for new apps that are sold in the Windows 8 app store. Win32 is only provided for backwards compatibility.
http://www.infoq.com/news/2011/09/WinRT

First Windows App Store? We are talking about a desktop OS here, bad mix.

Second, wach the call trace on your noce Windows 8 applications. You will see that many of the new API are calling through to GDI, and SystemXX, these are the Win32 core in windows 8. Just because it is hidden does not mean you are not using it.

And in my humble oppinion Windows 8 is very poorly designed. Most programmers that I know refuse to obey the new Windows 8 guidelines and still write Windows Applications that run perfectly well in windows 8.

Minix is a microkernel versus Linux which is a monolithic kernel. Minix has higher overhead for operation due the nature of microkernels: a privilege change (context switch) is required for interacting with its subsystems, and it is far more dependent on IPC (message passing).


This is well known. Thankfully the overhead is not as noticable as that in Linux.

At least it does not yet have the layers on layers of wrappers to contend with.

I highly recommend this. Upon completion you will have better understanding of the issues involved and may even reach the same conclusions others have.


And those would be?


1 Have you ran RISC OS? There is proof that faster is possible. Will not say much more till you run RISC OS for a bit.

2 I have dealt with all of this with much less capable HW than the RPi provides.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by OtherCrashOverride » Mon Sep 30, 2013 2:41 pm
DavidS wrote:Many of the GUI Libraries are still wrapped around X, and this is not like to change very quickly.

http://lists.freedesktop.org/archives/wayland-devel/2013-July/010280.html
GTK+, qt5, SDL, EFL and other applications can be used


DavidS wrote:Second, wach the call trace on your noce Windows 8 applications. You will see that many of the new API are calling through to GDI, and SystemXX, these are the Win32 core in windows 8. Just because it is hidden does not mean you are not using it.

Windows Runtime includes a subset of Win32; however, as stated before, GDI is legacy (obsolete).
http://msdn.microsoft.com/en-us/library/windows/desktop/hh309470%28v=vs.85%29.aspx

DavidS wrote:Have you ran RISC OS? There is proof that faster is possible

Simpler systems are faster because they are less functional. I can't use OpenGL, OpenVG, OpenMAX, or even Bluetooth on it much less mount my network shares. DOS is faster than RISC OS and Linux but less functional than either.

It really does not matter to me what OS you or anyone else uses. The point was to explain there is more to a "Fast GUI" on modern hardware than what people may think. SDL on PI is a good example of this because it was designed for a time before GPUs. The design is the issue same as Xlib.

As progress marched on, the automobile replaced the horse (or as Europeans call them: Beef). This is a time tested fact of life. Sometimes you have to throw everything away and start over, but there is room in the world for both horses and automobiles even today.
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am
by DavidS » Mon Sep 30, 2013 6:25 pm
Simpler systems are faster because they are less functional. I can't use OpenGL, OpenVG, OpenMAX, or even Bluetooth on it much less mount my network shares.

Those things have nothing to do with the speed of the system and there are examples of OSes much faster hthan RISC OS that can do all of those.

And yes you can mount your NFS shares under RISC OS, yes you can use blutooth. It is true that hardware 3d is not yet supported, though that is coming. And there you go expressing a particular API wanted, that some say is legacy.

DOS is faster than RISC OS and Linux but less functional than either.

You have not used DOS on HW equilivelent to that that you used RISC OS on if you believe that. DOS is as slow as you can get. This is largely do to its simplicity, it lacks support for good dynamic disk caching, it cals through the bios for text IO, etc.


It really does not matter to me what OS you or anyone else uses. The point was to explain there is more to a "Fast GUI" on modern hardware than what people may think.


Now that is true, and a duh. Though not only on modern HW. People also seem to think that over using the modern HW will speed up a GUI when that actually slows things down (examples accelerated xorg, Windows NT 5+, iOS, Apple OS X, accellerated Wayland all overdue it to slow themself down).


SDL on PI is a good example of this because it was designed for a time before GPUs. The design is the issue same as Xlib.

Now that I agree with completely.

Though with xlib the api is not the problem is the way that the server/client model is implemented.

With NanoX that issue does not exist, and there is provision for taking advantage of accellerated HW.

With accellerated wayland the issue is the over use of the GPU in an inefecient maner.

With SDL again the API is not the problem, the core archetechure is. The SDL api is still quite good, just needs to be completely remplemented to work well with accellerated video.


Just as with Linux with out a GUI the problem is not with the API it is with some of the implementation details. Such as the fact that pages will be swapped to disk even if there is still plenty of free memory, due to the Disk Paging algorithms used. Any of these issues can be solved with out changing the API.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by OtherCrashOverride » Mon Sep 30, 2013 6:42 pm
As Spongebob Squarepants would say: "Well... Good luck with that!"
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am
by DavidS » Mon Sep 30, 2013 9:36 pm
OtherCrashOverride wrote:As Spongebob Squarepants would say: "Well... Good luck with that!"

Who is this person???? Why is he/she supposed to be known??? Does she/he have something to do with GUI design or methods of graphics acceleration?? If so what projects?
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by AndrewS » Mon Sep 30, 2013 9:56 pm
I've not yet got round to trying it myself, but you seem to be talking about something similar to viewtopic.php?f=66&t=52220 ?
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by DavidS » Tue Oct 01, 2013 1:47 am
AndrewS wrote:I've not yet got round to trying it myself, but you seem to be talking about something similar to viewtopic.php?f=66&t=52220 ?

Thank you I was not aware of that one.

Yes I was speaking of a similar idea, though NanoX would require recompiling applications, where this MicroXwin that you pointed out does not. Thank you for that pointer.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by DavidS » Tue Oct 01, 2013 3:32 am
Finding myself beginning to rewrite the minix Kernel in assembly, and with a few different ideas on how to do some things, I am thinking that maybe it is time to rethink my method.

1: At this point I am thinking that maybe creating a simple kernel with the following properties:
    A: Implements a subset of the BSD kernel API, maintaining binary compatibility for the portions implemented.
    B: Written in 100% assembly language heavily optimized for the ARMv6 with HW dependent sections highly isolated in the source tree.
    C: Supports modules loaded into kernel space.

2: And using PDClib as the bases of a shared C library, extending slightly to support some of the POSIX extras.

3: Add a subset of xlib as a kernel module, providing a direct calling implementation instead of the client server crap:
    A: Make sure to provide enough to support FLTK, GTK+, and QT.
    B: Also make sure to provide support for at least the most common reparenting WMs.
    C: Make sure to provide support for HW acceleration, thus allowing extension to later support VideoCore IV acceleration.
    D: Make initial soft version to use DMA to implement some acceleration with out the help of VideoCore.
    E: Implement twice, once as a traditional region managed stacking style (though faster) system and once as a compossiting system sharing as much code as possible. Use which ever is the fastest.

4: Expand the API until most Linux stuff works with a simple recompile.

5: Port drivers for USB, GPIO, Network, etc.

6: Pick a suitable WebKit based web browser, port it and begin code profiling and recoding speed bottlenecks in hand optimized ARM assembly.

7: Port Electric VLSI, Squeak, Scratch, TCC, an assembler, ln, bash, and there dependancies using hand optimized ARM asm to get rid of speed bottlenecks.

8: go back through everything with an aim on reducing any memory leaks that the current versions have, and find any other bugs and optimizations that need to be dealt with.

9: Port enough third party Linux software to make it attractive to RPi users.

0xA: Release it under a MIT license.

0xB: Port Python (this is needed for 0xD)

0xC: Port at least three Structured BASIC compilers, though only ones that also have an interpreter.

AND:
0xD: Present it to the Raspberry Pi foundation, as yet another alternative OS.

0xE: Continue to maintain the core system.

0xF: Make a fork that only includes MIT and BSD licensed third party code by default.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by AndrewS » Tue Oct 01, 2013 4:15 am
That sounds incredibly ambitious, good luck with it all.
See you in 2015 when you've finished it? ;)
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by DavidS » Tue Oct 01, 2013 7:53 pm
AndrewS wrote:That sounds incredibly ambitious, good luck with it all.
See you in 2015 when you've finished it? ;)

I do not think that I am that quick :) .
More likely 2018.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA