New GUI for the Atari 8-bit

[flashjazzcat]

Ignore.

Edited August 29, 2014 by flashjazzcat

[danwinslow]

Ignore.

 

No!

[flashjazzcat]

 

Using Altirra's execution history, I found that the NMI mouse pointer consumes roughly 135,000 cycles per second. That, coupled with the other ISRs explains the baseline CPU load. Of course it was obvious that the "simulated hi-res sprite" mouse pointer would require more processing, since it must render every frame regardless of whether the pointer has moved or not, but it's been that way for a long time now and I figure the aesthetic justifies the work involved. I rather like the fact the pointer doesn't flicker when in front of the scrolling graph. MrFish and I are big on aesthetics.

 

Moving the mouse extends the IRQ execution time a little, and it would be nice to see this represented in the graph, but the graph has only 25 steps and the change in load must be less than four per cent. It'll show up in the numeric value, anyway.

 

[TXG/MNX]

Will there be a process tab in the taskmanager later ?

[Prodatron]

It's alive!!

[flashjazzcat]

Will there be a process tab in the taskmanager later ?

 

There will, and with per-process CPU usage: that's what I'm coding up now. Seems sensible to use tabs (in moderation), since it's quite a space-efficient interface element, and there'll be three: Applications, Processes (basically every task), and Performance (with the graphs).

[+MrFish]

Would it be possible to do a graph style like this?:

 

[Heaven/TQA]

Guys.... Amazing... Sorry to be repitive....

[+MrFish]

...or maybe even this?:

 

[pixelmischief]

There will, and with per-process CPU usage: that's what I'm coding up now. Seems sensible to use tabs (in moderation), since it's quite a space-efficient interface element, and there'll be three: Applications, Processes (basically every task), and Performance (with the graphs).

I wonder if perhaps you are letting Windows "get in the way", so to speak. You've already named the thing "Task Manager", which matches Windows. And now, you've outlined a design that will basically replicate the analogous tool on Windows; right down to everything being named the same. I'm not saying this is a mistake, but understanding your own assumptions as such might give you pause for thought toward a different design.

Edited August 30, 2014 by pixelmischief

[flashjazzcat]

I wonder if perhaps you are not letting Windows "get in the way", so to speak. You've already named the thing "Task Manager", which matches Windows. And now, you've outlined a design that will basically replicate the analogous tool on Windows; right down to everything being named the same. I'm not saying this is a mistake, but understanding your own assumptions as such might give you pause for thought toward a different design.

 

"Task Manager" is a place-holder. In fact I'm using SymbOS as a reference point for the basic design. Let's get it working first: there's plenty of time to redesign the dialogs later on. The lion's share of the work lies in writing the controls (list box, tabs, etc), not in arranging them in any particular order or putting a particular line of text in the drag-bar.

Edited August 30, 2014 by flashjazzcat

[+Stephen]

I wonder if perhaps you are letting Windows "get in the way", so to speak. You've already named the thing "Task Manager", which matches Windows. And now, you've outlined a design that will basically replicate the analogous tool on Windows; right down to everything being named the same. I'm not saying this is a mistake, but understanding your own assumptions as such might give you pause for thought toward a different design.

Why though? Tabbed interfaces are (IMHO) one of the best UI elements out there. I see nothing wrong with these tools - we are not trying to simulate a Mac or an ST.

[+Stephen]

 

Using Altirra's execution history, I found that the NMI mouse pointer consumes roughly 135,000 cycles per second. That, coupled with the other ISRs explains the baseline CPU load.

Question - would it be possible to have the pointer be turned off after not moving for a while or if requested by the application (until next move perhaps)? This could is essence like doing a POKE 559,0 for speeding up BASIC etc. Let's say we had a graphics intensive application - say we could hide the pointer while doing a 3D rotation.

[Stefan Both]

Dont call it "Schnitzel' ???

Why shouldnt he call a task manager a task manager?

I dont mind. As long as it works, it looks really good.

[flashjazzcat]

Question - would it be possible to have the pointer be turned off after not moving for a while or if requested by the application (until next move perhaps)? This could is essence like doing a POKE 559,0 for speeding up BASIC etc. Let's say we had a graphics intensive application - say we could hide the pointer while doing a 3D rotation.

 

Sounds reasonable. We could also let the user choose the flickery pointer option if they wanted, then all the bases are covered. Not that we should get too preoccupied with this at the moment, since this is the same mouse pointer which was present when the new window manager was supposedly wowing onlookers with its speed a year ago. In fact, it's pretty ironic that - having started with a flickering mouse pointer, I was persuaded to use the current system, which I did after carefully weighing up the pros and cons. Each method will obviously have its advocates, and one can't simultaneously please both. There's certainly something to be said for pleasing oneself.

 

Note that even if an NMI doesn't fire in the middle of the idle task's quantum, the values of VCOUNT at the start and end don't change, so nor does the graph:

 

 

Edited August 30, 2014 by flashjazzcat

[+Stephen]

 

Sounds reasonable. We could also let the user choose the flickery pointer option if they wanted, then all the bases are covered. Not that we should get too preoccupied with this at the moment, since this is the same mouse pointer which was present when the new window manager was supposedly wowing onlookers with its speed a year ago. In fact, it's pretty ironic that - having started with a flickering mouse pointer, I was persuaded to use the current system, which I did after carefully weighing up the pros and cons. Each method will obviously have its advocates, and one can't simultaneously please both. There's certainly something to be said for pleasing oneself.

HAHA - well, to quote our fearless leader, I wouldn't want to put the cart before the horse. I understand you have no plan for this pressing issue Just more thinking out loud.

[flashjazzcat]

Just more thinking out loud.

Well, your suggestion is a good one, and has been taken on board.

[flashjazzcat]

Oops - nearly missed these Paul:

 

Would it be possible to do a graph style like this?:

 

TM Graph.png

...or maybe even this?:

 

TM Graph 2.png

Yeah - both look good, and both easy to code up. Thanks!

 

EDIT: here's an approximation of method 1:

 

 

Graph should really be trimmed down by 1px horizontally so we have a vertical black border at both sides. The other method - while prettier - obviously lacks granularity, unless we make the graph much taller.

Edited August 30, 2014 by flashjazzcat

[+Stephen]

Yeah - both look good, and both easy to code up. Thanks!

Just now told the gf, this is why every good programmer needs a good graphician.

[+Stephen]

Hey fj - your mailbox must be full. Clean out the Centron 3D shit

 

 

 

Hey - jump on IRC if ya can (should be 7:12 or 8:12 your time - I am (time) retarded).

[Irgendwer]

 

We could also let the user choose the flickery pointer option if they wanted, then all the bases are covered.

 

Without knowing anything about the current mouse pointer displaying routine, could it make sense to save some cycles by comparing the current screen data with buffered one?

Example:

Mouse pointer has to be updated if

* moved

* two screen memory bytes * height, beginning at the current position have changed (so there was a graphic updated beneath, mouse pointer display region has to be refreshed)

 

like

lda currentScreenData(+x+y*width)

cmp bufferedMouseScreenData(+x+y*width)

bne doTheCompleteMaskingMousePointerOntoScreenRout

 

How many times is the mouse pointer updated? Every VBI?

 

(BTW: Looks quite promising!)

[flashjazzcat]

Just now told the gf, this is why every good programmer needs a good graphician.

Yep: I think I said in another - erm - discussion: it's a rare coder who is also best placed to design his own graphics (although I guess MrFish is one of those rare cases).

 

Without knowing anything about the current mouse pointer displaying routine, could it make sense to save some cycles by comparing the current screen data with buffered one?

Example:

Mouse pointer has to be updated if

* moved

* two screen memory bytes * height, beginning at the current position have changed (so there was a graphic updated beneath, mouse pointer display region has to be refreshed)

 

like

lda currentScreenData(+x+y*width)

cmp bufferedMouseScreenData(+x+y*width)

bne doTheCompleteMaskingMousePointerOntoScreenRout

When we were using the flickering routine, I actually developed just such a masked drawing routine which effectively drew "around" the pointer, updating the background buffer when necessary. This meant the pointer could be rendered only when it was moved, but the graphics rendering took a hit because of performing these coordinate checks. Maybe the two methods would even out at the end of the day - who knows. But not having to care about the mouse pointer in the graphics routines certainly simplified rendering no end.

 

How many times is the mouse pointer updated? Every VBI?

It's drawn once per frame, just before the raster line displays it, and then erased immediately afterwards. The pointer does not exist outside of the interrupt.

 

Hey fj - your mailbox must be full. Clean out the Centron 3D shit

OK - will do. Thanks for letting me know.

Edited August 30, 2014 by flashjazzcat

[Irgendwer]

When we were using the flickering routine, I actually developed just such a masked drawing routine which effectively drew "around" the pointer, updating the background buffer when necessary. This meant the pointer could be rendered only when it was moved, but the graphics rendering took a hit because of performing these coordinate checks. Maybe the two methods would even out at the end of the day - who knows. But not having to care about the mouse pointer in the graphics routines certainly simplified rendering no end.

 

For sure. Thanks for the insight. So when the mouse pointer isn't moved, you have to redraw it anyway since it is cleared with the 'original' screen data.

So you already store the original screen data and could compare if it was changed and you are able to apply the same bytes where the pointer was masked to one frame before!?

Edited August 30, 2014 by Irgendwer

[flashjazzcat]

For sure. Thanks for the insight. So when the mouse pointer isn't moved, you have to redraw it anyway since it is cleared with the 'original' screen data.

Correct: the single drawback of what is a really cool method of rendering the pointer (and I say that because it wasn't me who came up with the idea).

 

So you already store the original screen data and could compare if it was changed and you are able to apply the same bytes where the pointer was masked to one frame before!?

No. We optimised the bejesus out of the pointer renderer (ways back in this thread) until the background ended up being cached in the same loop that draws the pointer. So it's tight as hell; the only wasted time is a VCOUNT wait so we don't erase the thing too soon (and this ensures it works on an 65816 as well). Of course the wait prior to erasing (until VCOUNT has ticked over eight times since the NMI fired) could be used to perform other useful work, I guess.

Edited August 30, 2014 by flashjazzcat

[+MrFish]

The other method - while prettier - obviously lacks granularity, unless we make the graph much taller.

 

Try something like this then: