Window refresh problems under Geneva/Neodesk

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

emcclariion
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 108
Joined: Wed Nov 28, 2012 6:37 pm

Re: Window refresh problems under Geneva/Neodesk

Postby emcclariion » Wed Oct 03, 2018 7:13 am

This would be great port for Gem, as there is no BBS clients which work with sting.

there is one, but its so basic no point using it on a BBS
Mega STE 4MB, AlberTT and Atari STE 4MB TOS 2.06 Netusb Ultrasatan 2

tschak909
Atari maniac
Atari maniac
Posts: 83
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Wed Oct 03, 2018 12:51 pm

This is a very special terminal, it does not do VT-100 emulation, but rather for a special terminal type which supports graphics and mouse (touch panel) interaction. Intended to be used with a handful of systems which are currently deployed to support it (namely IRATA.ONLINE).

-Thom

User avatar
Ektus
Captain Atari
Captain Atari
Posts: 225
Joined: Mon May 24, 2010 2:58 am
Location: Germany
Contact:

Re: Window refresh problems under Geneva/Neodesk

Postby Ektus » Wed Oct 03, 2018 1:01 pm

As for missing packages on a serial connection: Do you have HSMODEM installed to get a small buffer?

Search for archive HSMODA07, e.g. on https://sites.google.com/site/stessenti ... l-software

Regards
Ektus.
Schneider CPC464 (long retired), Atari Mega ST4 (retired), Falcon+CT2A, Falcon+CT63+CTPCI+Radeon 9250, Milan040+SCSI+Rage

tschak909
Atari maniac
Atari maniac
Posts: 83
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Wed Oct 03, 2018 4:33 pm

to reply to @WongCK:
---------------------------

This is the screen queue:

Code: Select all

#ifndef SCREEN_QUEUE_H
#define SCREEN_QUEUE_H

#include "protocol.h"

typedef enum _screen_op_type {
  SCREEN_OP_DOT,
  SCREEN_OP_LINE,
  SCREEN_OP_ALPHA,
  SCREEN_OP_BLOCK_DRAW,
  SCREEN_OP_PAINT,
  SCREEN_OP_CLEAR,
} ScreenOpType;

typedef struct _screen_op {
  ScreenOpType type;
  padPt Coord1;
  padPt Coord2;
  padRGB foreground;
  padRGB background;
  char text[64];
  unsigned char count;
  CharMem textMem;
  padBool TTY;
  padBool ModeBold;
  padBool Rotate;
  padBool CurMode;
} ScreenOp;

typedef struct _screen_op_node {
  ScreenOp op;
  struct _screen_op_node* next;
} ScreenOpNode;



So you essentially have, a type, two sets of coordinates, color, a text buffer/count if needed, and the terminal state at that moment.

These are rippled through when a redraw happens.

I have TRIED to do an optimization where if a redraw happens as a result of something being ADDED to the queue, then only the top-most entry is rendered again.... am trying to debug that.

-Thom

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2250
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Window refresh problems under Geneva/Neodesk

Postby calimero » Wed Oct 03, 2018 10:45 pm

ThorstenOtto wrote:
tschak909 wrote:(For the record, I am having none of these issues with any of the other ports, including the Amiga. GEM is an unbelievable pain in the arse.)


I can't really believe that it is *that* much different. I don't know much about amiga, but the basic principle, that someone is telling you that you have to redraw your window, is almost the same everywhere.


Heh... I just want to ask how all these problems are handled by Amiga OS... ?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12497
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Window refresh problems under Geneva/Neodesk

Postby wongck » Wed Oct 03, 2018 11:38 pm

tschak909 wrote:So you essentially have, a type, two sets of coordinates, color, a text buffer/count if needed, and the terminal state at that moment.

These are rippled through when a redraw happens.

I have TRIED to do an optimization where if a redraw happens as a result of something being ADDED to the queue, then only the top-most entry is rendered again.... am trying to debug that.

-Thom


So I guess you are still working on a Windowed version, and not a TOS or better say a "non-windowed version that writes to whole screen", as you still working on the redrawing windows.

Just looking at how a user will be using your application... user will have it as the top-most window most of the time and on a 512KB 520 ST 100% as there is no multitasking OS. Even on a multitasking OS, the user will be reading/responding to the window 90-95% of the time. May be now and then the user will switch to other application to do something forcing a redraw.

So a slow redraw will not plague your application much, so long as new information to be display does not force a total redraw on itself.

Back to the non-windowed implementation, it would probably be like a game with double buffering, it draw in memory and blit to the screen. Like offscreen bitmaps.
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

arf
Captain Atari
Captain Atari
Posts: 183
Joined: Thu May 17, 2012 9:56 pm
Location: Germany

Re: Window refresh problems under Geneva/Neodesk

Postby arf » Thu Oct 04, 2018 1:31 am

tschak909 wrote:I'm already noticing that even with debugging the redraw issues, the performance eaten by attempting to maintain the screen queue is enough to make the modem miss incoming data. This is even in 25mhz on a TT030.

I will probably have to go back to my original mode of literally just painting over the top in full screen, only do full screen, and don't do any additional dialog boxes (for the keys/help menu).

poo.

(For the record, I am having none of these issues with any of the other ports, including the Amiga. GEM is an unbelievable pain in the arse.)


Other communication software as CoNnect, manages to keep up the speed to display Tek4014 graphics, in GEM windows, coming in via serial port. I don’t know the PLATO protocol, but I think you mentioned some principal similarity to 4014 in the beginning of the discussion.

tschak909
Atari maniac
Atari maniac
Posts: 83
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Thu Oct 04, 2018 1:40 am

Great. Does it have source code? Otherwise, comparison is moot. I am working with what I can do here.

getting rather irritated.

-Thom

tschak909
Atari maniac
Atari maniac
Posts: 83
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Thu Oct 04, 2018 1:56 am

I'll debug the drawing glitches that I currently have, and paste a binary here.

-Thom

tschak909
Atari maniac
Atari maniac
Posts: 83
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Thu Oct 04, 2018 5:46 am

It looks like I will need to write an interrupt driven serial receive routine. I will need to dig in and see what needs to happen for that to work. Has anybody here done anything like that?

-Thom

joska
Hardware Guru
Hardware Guru
Posts: 4181
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Window refresh problems under Geneva/Neodesk

Postby joska » Thu Oct 04, 2018 7:23 am

wongck wrote:Just looking at how a user will be using your application... user will have it as the top-most window most of the time and on a 512KB 520 ST 100% as there is no multitasking OS. Even on a multitasking OS, the user will be reading/responding to the window 90-95% of the time. May be now and then the user will switch to other application to do something forcing a redraw.

So a slow redraw will not plague your application much, so long as new information to be display does not force a total redraw on itself.

Back to the non-windowed implementation, it would probably be like a game with double buffering, it draw in memory and blit to the screen. Like offscreen bitmaps.


As you say, redraw speed only matters when the user is interacting with the application, and in that case the window will be on top. That means no (or very few) redraws - graphics will only have to be output once. Drawing directly to screen will be the fastest approach, any offscreen bitmaps will slow down output.

tschak909 wrote:It looks like I will need to write an interrupt driven serial receive routine. I will need to dig in and see what needs to happen for that to work. Has anybody here done anything like that?


See Ektus' post... HSModem is exactly what you need.
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

tschak909
Atari maniac
Atari maniac
Posts: 83
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Thu Oct 04, 2018 3:24 pm

Thanks to everyone who has replied so far....

I've now tested most of what has been suggested...it's clear from all the empirical testing, that trying to handle ALL the drawing through the nominal clip/redraw mechanism that AES exposes imposes way too much overhead given the # of VDI calls that get clustered together, all the while serial data is coming in...

If I do VDI calls directly, I can get a decent amount of performance that doesn't collapse under higher baud rates.

SOOOO....

Looks like I will do the following:

(1) serial data comes in, keep grabbing data until the buffer is empty, hold in secondary buffer.
(2) send secondary buffer through ShowPLATO.
(3) For each drawing operation, stash in redraw queue
(4) when window is TOPPED, just override and draw directly onto surface.
(5) otherwise, fall back to method I am doing in window redux which,
(5a) each new entry in queue gets immediately dirty-rected for redraw
(5b) redraw happens for that rect.

Hopefully, this will work...

-Thom

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2250
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Window refresh problems under Geneva/Neodesk

Postby calimero » Thu Oct 04, 2018 6:17 pm

Thanks tschak909 for support and time dedicated to ST!

If you find time, could you write few lines comparing how Amiga Workbench handle windows, events... comparing to GEM?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

arf
Captain Atari
Captain Atari
Posts: 183
Joined: Thu May 17, 2012 9:56 pm
Location: Germany

Re: Window refresh problems under Geneva/Neodesk

Postby arf » Thu Oct 04, 2018 9:33 pm

tschak909 wrote:It looks like I will need to write an interrupt driven serial receive routine. I will need to dig in and see what needs to happen for that to work. Has anybody here done anything like that?

-Thom


Did you have a look at HSMODA, ver. 007?

tschak909
Atari maniac
Atari maniac
Posts: 83
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Fri Oct 05, 2018 4:00 am

Okay, further grinding...

(yes, I have looked at HSMOD)

The simple act of writing the drawing queue slows the program down enough as to adversely impact overall performance.

I have tried every variation I can think of to try and speed this up, (even going as far as dispensing with the singly linked list and dealing with a linear fixed size array arranged like a ring buffer)...

I have kept the results in screen_queue_redux and fixed_array_screen_queue branches.
https://github.com/tschak909/platoterms ... ueue_redux
https://github.com/tschak909/platoterms ... reen_queue

but for now, I will dispense with them, and deal with this as a full screen app. The little forms that pop up for special keys and serial settings will not redraw the screen behind them, but rather simply clear what's behind, for now...and all screen operations will be direct VDI with no clipping for now.

this way, at least, you get a usable terminal at fast speeds (19200+) without things going sideways.

I tried, fellas.

I really tried, and I'm conceding defeat on trying to make things redraw nicely.

If anyone can figure this out and improve what's there, please have at it. I need to move on and get this terminal to a feature complete state (namely, get the mouse to touch screen mapping done so that the mouse can be used to select items when the touch screen is enabled by a lesson)

-Thom


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 3 guests