New GUI for the Atari 8-bit

[+MrFish]

Here's the same thing with the black graph style:

 

Edited September 1, 2014 by MrFish

[Prodatron]

I think it's as accurate as it's going to get. If idle is running 70 per cent of the time, we can deduce the rest is IRQ (mouse, scheduler), NMI (mouse pointer, vertical blank), kernel entry/exit, and the inexact nature of measurement (i.e. sampling VCOUNT at the start and end of a task quantum).

I digged out one of the first SymbOS versions with running scheduler from end of 2004 and made some tests. When nothing is running, the idle task gets 86% CPU time. So the scheduler and the system processes used 16%. In the actual version the idle task gets 93% CPU time, so it was possible to reduce the usage of the scheduler and system processes to 7%. So I am quite sure, that you can reduce these 30% somehow, too.

 

I wonder how much additional load the Task Manager adds. Not only because of the display but also due to the fact, that the kernel is keeping measuring the VCOUNTs (which it doesn't do if there is no task manager running). At the beginning the Task Manager took 6%, now it's taking 3% CPU time if it's fully visible and located at a byte aligned screen position.

 

 

@MrFish: Wow, that's my favourite one!!

Edited September 1, 2014 by Prodatron

[+MrFish]

OK, one last minor variation, and then I'll quite for a while:

 

 

[+MrFish]

Alright, one last one -- this time with a little bit of a 3D look:

 

 

 

[pixelmischief]

OK, one last minor variation, and then I'll quite for a while:

 

TM Graph 17a (In Situ, Scaled).png

I like this one best. The fat font with the thick border is fun; a little "game-y".

[pixelmischief]

Also, maybe colons after the field labels?

[jacobus]

Jon

 

Amazing work - things just get more and more interesting here!

 

Quick question - when it comes to the GUIs I've worked with over the years, I've almost always felt the need for more desktop real estate. Some older systems had a way of providing a larger area by scrolling the desktop when the mouse pointer reached an edge of the screen. (I think I remember this on the ST and possibly the early Macs). Is it even remotely possible to implement such a system on your GUI? I'm not asking this as a feature request, but simply out of curiosity.

[Mr.Amiga500]

 

I always think of this version:

(Spanish subtitles - couldn't find HD version without subtitles)

 

 

Nice! I'm not taken with the reversed-out section titles for some reason, but I love the tabs, graphs and text placement. Very sensible use of space.

 

 

Why don't you like reversed text for titles? I think it's clearer to read quickly rather than having an entire window of white.

[+Stephen]

Why don't you like reversed text for titles? I think it's clearer to read quickly rather than having an entire window of white.

I agree - it tends to break up the window a bit. I'd imagine this will all be configurable though.

[flashjazzcat]

Here's the same thing with the black graph style:

 

TM Graph 16 (In Situ, Scaled).png

That's the best one.

 

I digged out one of the first SymbOS versions with running scheduler from end of 2004 and made some tests. When nothing is running, the idle task gets 86% CPU time. So the scheduler and the system processes used 16%. In the actual version the idle task gets 93% CPU time, so it was possible to reduce the usage of the scheduler and system processes to 7%. So I am quite sure, that you can reduce these 30% somehow, too.

 

I wonder how much additional load the Task Manager adds. Not only because of the display but also due to the fact, that the kernel is keeping measuring the VCOUNTs (which it doesn't do if there is no task manager running). At the beginning the Task Manager took 6%, now it's taking 3% CPU time if it's fully visible and located at a byte aligned screen position.

As we were saying before, the mouse pointer on the A8 is consuming about ten per cent of the available cycles. SymbOS's task manager appears to show 11% CPU usage when nothing is happening (in WinAPE), although this climbs when the mouse pointer is moved. We get no (discernible) increase when moving the pointer, but I guess that's just because of the different implementations. VCOUNT sampling can't take much time, and the task manager currently sleeps until it's woken up by the kernel (every time a sample is ready). I guess we'll squeeze it down when time is available. Turning the mouse off would probably drop idle CPU usage down to - what - 15 per cent? It'll be interesting to further optimise the kernel and scheduler over time anyway. I haven't yet gotten rid of BRK kernel entry, as per Jac!'s indisputable advice (which - IIRC - I said had a 17,000 cycle per second overhead).

 

EDIT: No - turning off the mouse makes no difference, since what's measured isn't cycles spent executing a task, but VCOUNT ticks elapsed between quantum start and end, and interrupts firing mid-time-slice don't change this. I'm going to take time to run some profiling here to find out more.

 

Quick question - when it comes to the GUIs I've worked with over the years, I've almost always felt the need for more desktop real estate. Some older systems had a way of providing a larger area by scrolling the desktop when the mouse pointer reached an edge of the screen. (I think I remember this on the ST and possibly the early Macs). Is it even remotely possible to implement such a system on your GUI? I'm not asking this as a feature request, but simply out of curiosity.

Fair question. I considered this in the past as well (especially when asked to support lower resolutions and higher bit-depths), but with the frame buffer in main memory, I fear we'd lack the space to do proper hardware scrolling (which I think would be the optimal way to scroll across a large canvas on the A8).

 

We could always do Mac OS "Spaces", though.

 

I agree - it tends to break up the window a bit. I'd imagine this will all be configurable though.

Not the general appearance of dialogs. This is why dialog font, spacing and control proportions need to be decided on early, before I waste time coding up dialogs which will need to be changed later. The thing about the reversed out regions as static material - apart from the taste question - is that a highlighted section is one of the methods used to denote a selected item (see menus).

 

I'm half inclined to make the design of the CPU graph configurable, since that also appears subject to mass debate. In any case, if I'm going to get a demo finished inside of a week, I need to get all three tabs of the Activity Manager or whatever it's called working, make changes to the menu bar, and fix several bugs.

Edited September 2, 2014 by flashjazzcat

[Prodatron]

That's the best one.

Still my favourite one, too!

 

As we were saying before, the mouse pointer on the A8 is consuming about ten per cent of the available cycles.

What's about having two modes:

- mouse pointer isn't moving and is not placed in front of a screen element, which is currently updated. In this case you could only plot it once without hiding/showing each frame.

- mouse is moving or in front of currently updated screen elements. In this case you do the current methode.

 

SymbOS's task manager appears to show 11% CPU usage when nothing is happening (in WinAPE), although this climbs when the mouse pointer is moved.

When you kill the screen saver and the extension process, you will get 10% CPU usage. By starting a second task manager (and place it at another byte aligned position) you can figure out, that each Task Manager takes 3% (as now the CPU usage is +3%). So 10 - 3 = 7. Well, that was my way to figure it out

[flashjazzcat]

What's about having two modes:

- mouse pointer isn't moving and is not placed in front of a screen element, which is currently updated. In this case you could only plot it once without hiding/showing each frame.

- mouse is moving or in front of currently updated screen elements. In this case you do the current methode.

Hmmm... this is what I'll look into if it becomes a problem. But the NMI doesn't affect the start and end values of VCOUNT, and therefore is not the reason for the 30 per cent base reading.

 

When you kill the screen saver and the extension process, you will get 10% CPU usage. By starting a second task manager (and place it at another byte aligned position) you can figure out, that each Task Manager takes 3% (as now the CPU usage is +3%). So 10 - 3 = 7. Well, that was my way to figure it out

Heh... and owing to my kludgy kernel sample function, I can't run two task managers. But no matter. I spent two hours poring over the code this evening before I realized my mistake: I'd set up a counter (SampleFrameCount) which was supposed to be decremented fifty times per second, but I'd forgotten I was running the scheduler IRQ (which was handling the counter) at 64Hz. Therefore the sample period wasn't long enough to make the numbers accurate.

 

So - with that fixed, Idle didn't change much when nothing else was busy (Idle 69%, Desktop 26%, System 3%), but at least the totals are just about adding up now. Obviously my attention was grabbed by the Desktop Manager, which shouldn't really need 26 per cent of the processor to render the bitmap once every couple of seconds. Sure enough the bitmap renderer I whipped up the other day turns out to be a bit slow, so I'll work on that a bit and see what it does.

[danwinslow]

I'm half inclined to make the design of the CPU graph configurable, since that also appears subject to mass debate. In any case, if I'm going to get a demo finished inside of a week, I need to get all three tabs of the Activity Manager or whatever it's called working, make changes to the menu bar, and fix several bugs.

 

Well, maybe the tack to take is to make the Task Manager the first app. What I mean is, I get the impression you are sort of hard coding it into the GUI, and not really setting it up as you would an actual app. So, you'd need to expose whatever internals are needed to call to get the values, but the actual design of the app presentation itself would be all up to the app designer, and resource files, etc. My point is that if you aren't hardcoding it into the GUI, you can just tell people to design their own to suit them, and dodge all the debate. BUt, you probably aren't at that stage with the app support yet, so maybe not.

[pixelmischief]

Well, maybe the tack to take is to make the Task Manager the first app. What I mean is, I get the impression you are sort of hard coding it into the GUI, and not really setting it up as you would an actual app. So, you'd need to expose whatever internals are needed to call to get the values, but the actual design of the app presentation itself would be all up to the app designer, and resource files, etc. My point is that if you aren't hardcoding it into the GUI, you can just tell people to design their own to suit them, and dodge all the debate. BUt, you probably aren't at that stage with the app support yet, so maybe not.

Well, I think the idea is to eventually have a windowing manager API on which applications will be based. But until that is ready, this task manager still offers interesting, maybe vital information. Even if a later version will use the widget set that the API must eventually offer. In any case, it makes for an almost unbelievable demonstration of what's possible.

Edited September 2, 2014 by pixelmischief

[danwinslow]

Well, I think the idea is to eventually have a windowing manager API on which applications will be based. But until that is ready, this task manager still offers interesting, maybe vital information. Even if a later version will use the widget set that the API must eventually offer. In any case, it makes for an almost unbelievable demonstration of what's possible.

 

Indeed it is!

[flashjazzcat]

Well, maybe the tack to take is to make the Task Manager the first app. What I mean is, I get the impression you are sort of hard coding it into the GUI, and not really setting it up as you would an actual app. So, you'd need to expose whatever internals are needed to call to get the values, but the actual design of the app presentation itself would be all up to the app designer, and resource files, etc. My point is that if you aren't hardcoding it into the GUI, you can just tell people to design their own to suit them, and dodge all the debate. BUt, you probably aren't at that stage with the app support yet, so maybe not.

If that's the impression given, it's unintentional. The task manager is coded up as an application (from a self-contained source file), using the same API that other applications will eventually use. It uses message passing and supervisor calls in exactly the same way as the desktop application (which is also a standard application). The task manager doesn't directly access any internal information; it uses a kernel call which returns a buffer of task records.

 

Because of this, the task manager is effectively the first fully functional application with the first fully functioning dialog box. Designing it is helping us get a picture of UI considerations which will later propagate across other applications and dictate the general look and feel of the whole system.

 

I was only half serious when I suggested making the design of the graph user-configurable. I really don't want to spend too much time bogged down in over-engineering one small piece of the very large puzzle.

 

Well, I think the idea is to eventually have a windowing manager API on which applications will be based. But until that is ready, this task manager still offers interesting, maybe vital information. Even if a later version will use the widget set that the API must eventually offer.

Yep: it's a window manager API and that's what's being used now, by the task manager, which is using the standard widget set (tab control, frames, labels, buttons, etc). The graph is the single element which isn't a widget: it's a bitmap defined in the task manager application (although the bitmap control itself is a widget). Most applications will be made up of standard controls, and anything - like the graph - which isn't already handled by a standard control can be coded up as a bitmap (this is how the main display of SymbOS's version of Pacman works). Obviously standard controls encourage uniform application design, although developers will be free to use subtle variations on the defaults (different fonts and styles, button designs, etc), and implement non-standard stuff as raw bitmaps. Since the task manager is the first full application using the API, it provides an opportunity to get the design of all the controls it uses more-or-less finalised more-or-less now, even if the placement of said controls might continue to change.

 

Tabs are working now; here are the control types used on the monitor tab of the un-prettified task manager:

 

 

1. Tab control

2. Bitmap control

3. Titled frame

4. Label control

 

The other tabs will require command buttons and list boxes. The list box will require (or incorporate) a column heading control with clickable headings which will cause the list data to be sorted in ascending/descending order on the chosen column.

Edited September 3, 2014 by flashjazzcat

[Prodatron]

Because of this, the task manager is effectively the first fully functional application with the first fully functioning dialog box.

Did you already define a structure for apps? Something like header, code/data, relocator table etc.?

[flashjazzcat]

Did you already define a structure for apps? Something like header, code/data, relocator table etc.?

Yeah, roughly: I'll write it up when it's finalized, of course. Right now the header is simply the application name and a byte in which the OS stores the base bank of the code, so the application knows where it lives. MADS (the compiler) handles the relocation table: this always goes at the end of the file, in separate segments. Obviously if we end up supporting alternative formats (such as home-brewed relocatables made with other compilers), those formats will have to be documented too.

 

This is the top of the task manager's source code:

 

	.local Profiler
	.byte 0
	.byte 'Profiler'
	mva Profiler MessageBuffer+1 ; bank
	mwa #Window1 MessageBuffer+2 ; address
	mva #Desk.WindOpen MessageBuffer ; function
	jsr SendMsgDeskMgr ; send message
	jsr SleepMsgDeskMgr ; sleep till we get a response
	mva MessageBuffer+4 Window1ID ; get window ID (only valid if status is OK)
	lda MessageBuffer ; get status (bit 7 set if there was an error)

I'm pleased that the whole thing - code, data, generous comments, and all - only comes in at 320 lines of source at the moment. The binary is 688 bytes long, although there is currently no relocation table in this developmental setup. This is encouraging; GUI applications are obviously going to be quite small.

[flashjazzcat]

Prodatron: I was looking at some ways of optimising the scheduler and I wonder if you are moving sleeping/idle tasks out of the run queue entirely until they become ready again. I'm using a forward linked list (from highest priority to lowest). Some systems even have different queues for each priority level.

[pixelmischief]

Yep: it's a window manager API and that's what's being used now, by the task manager, which is using the standard widget set (tab control, frames, labels, buttons, etc).

That is freaking amazing. I never would have thought that performance was possible at all, let alone from API calls. Your widget library is looking very nice. Can you measure performance right down to the widget; so that developers will know how "heavy" a dialogue is going to be?

 

*EDIT*

I guess that will be a documentation task, best left for later

Edited September 3, 2014 by pixelmischief

[flashjazzcat]

Prodatron: I was looking at some ways of optimising the scheduler and I wonder if you are moving sleeping/idle tasks out of the run queue entirely until they become ready again. I'm using a forward linked list (from highest priority to lowest). Some systems even have different queues for each priority level.

[flashjazzcat]

Can you measure performance right down to the widget; so that developers will know how "heavy" a dialogue is going to be?

 

As you say: that'll be a documentation job. Most controls get heavier the more text they display. Therefore, keying something into a text editor's multi-line text control is obviously going to tie up the CPU for a second or two while the control redraws. The UI has the highest task priority and is never preempted unless another task is given the same top-level priority. The UI's performance would fall apart otherwise.

[Prodatron]

Prodatron: I was looking at some ways of optimising the scheduler and I wonder if you are moving sleeping/idle tasks out of the run queue entirely until they become ready again. I'm using a forward linked list (from highest priority to lowest). Some systems even have different queues for each priority level.

- Idle tasks are just these ones, which are currently running but return CPU time quite fast by themself. So they are still in the queue as they will be called during the next cycle.

- Sleeping tasks are removed completely from the queue indeed. The list of processes inside the scheduler is pointer based, so it's not a big issue to remove these sleeping tasks, but it really saves some CPU time.

[flashjazzcat]

- Idle tasks are just these ones, which are currently running but return CPU time quite fast by themself. So they are still in the queue as they will be called during the next cycle.

Yes: I didn't mean to say Idle there. Idle is a different state and handled exactly as you describe.

 

- Sleeping tasks are removed completely from the queue indeed. The list of processes inside the scheduler is pointer based, so it's not a big issue to remove these sleeping tasks, but it really saves some CPU time.

As I thought. I'm investigating using different queues for different priority levels, in fact, since I think this could be even faster than walking a long list to re-insert a task which has just woken up. One could simply add it to the head of the appropriate priority list.

 

I'll try some of these ideas at the weekend, since I realize that level of idle CPU usage can be caused by nothing other than scheduler and message passing latency, and of course the mouse pointer. The CPU usage measurement simply picks up where the last task was interrupted, so any interrupts which fire while the desktop manager is checking for mouse events or messages will simply extend that process's measured processor usage. In any case: there'll be plenty of time to optimise once bugs are eliminated, and I'm rather grateful the whole thing isn't flatlining at 100 per cent. BRK entry also needs to be dispensed with; this (owing to the 64Hz scheduler) will save over 20,000 cycles per second. It might also be worth dropping the IRQ frequency to 50Hz (in fact, if this is done, the scheduler would be better off running in the NMI).

 

I'd hoped to have the task manager completed tonight (using some of MrFish's design elements, particularly regarding graph size), but the task manager overspilled the bit of cartridge bank space it was occupying, so I did what I had been delaying for a while and changed things so that the task manager is installed into a different bank of extended RAM (of course small applications will be able to share extended banks when the relocator is used, but for now, the desktop application and the task manager each run in their own 16KB bank). I then instantly discovered another bug in the message send routine (when more than a single message was pending for a given process, the pending message count was wrong). The bug fixed, the task manager can now send redraw messages for two controls one after another. This won't be necessary once RedrawControl can redraw n controls starting at control ID x (currently it only redraws all controls, or a single one).

 

 

In any case, the graph and the titled frame are both now redrawn every time the sample data changes.

 

Note: occasional very ugly redraw effects are caused by video encoding, I'm afraid.

Edited September 3, 2014 by flashjazzcat

[barnsey123]

Concerning screen real-estate...

 

A mockup of a screen allowing the selection of multiple desktops (limited only by available memory) based on a screenshot from MrFish

 

The "Desktop" menu (top) would allow the creation/deletion/selection of named desktops. No scrolling necessary, "just" draw a new screen. The buttons at bottom left/right would allow quick navigation.

Erm..It's just a thought...I'll get my coat...taxi for barnsey!