Window refresh problems under Geneva/Neodesk

GFA, ASM, STOS, ...

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

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

Window refresh problems under Geneva/Neodesk

Postby tschak909 » Fri Sep 28, 2018 7:41 pm

I am in the middle of working through my implementation of PLATOTerm for the Atari ST, and I am attempting to test on multiple desktop environments.

To start with, am using WinDOM 2 as my app framework.

The code and branch I am working on, is here:
https://github.com/tschak909/platoterms ... indow_work

I have a setup in Hatari which provides a TT030, which boots into Geneva/Neodesk, and I have it set up to use an extended VDI screen, so that I can have a large desktop to test my windowed functionality.

If PLATOTerm is run with a screen resolution greater than 640x480, then the application creates a window which is 512x512, and draws into it, otherwise, the application draws a window the size of the screen, and blanks out the window controls and disables menu bar, making it a full screen application. This works fine.

The application also keeps a terminal buffer, which is re-played when a redraw needs to happen. This buffer is cleared when my terminal clears its screen.

However, when testing in windowed mode, things go strange:

The application re-maps the palette, because PLATO can support color. I have a function which iterates through the entire palette, and re-maps it whole cloth. However, I only see the background color change, and the window remains blank. If I click off of it, onto another window, the window contents appear instantly (they were there, already, but obscured by the palette, it seems). If I click off to another window, and back, the palette completely re-maps, and I can see my output, in its correct form.

Also, how can I determine whether my window is selected or not? Sometimes, a window redraw isn't being asked for, so occasionally my palette does not get re-mapped when the window comes to front, or it doesn't get re-mapped by the OS when another window (e.g. a NeoDesk file window) comes to front.

Finding well-behaved patterns in ST application design seems to be an exercise in utter frustration...

-Thom

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

Re: Window refresh problems under Geneva/Neodesk

Postby arf » Fri Sep 28, 2018 8:12 pm

tschak909 wrote:However, when testing in windowed mode, things go strange:

The application re-maps the palette, because PLATO can support color. I have a function which iterates through the entire palette, and re-maps it whole cloth. However, I only see the background color change, and the window remains blank. If I click off of it, onto another window, the window contents appear instantly (they were there, already, but obscured by the palette, it seems). If I click off to another window, and back, the palette completely re-maps, and I can see my output, in its correct form.

Also, how can I determine whether my window is selected or not? Sometimes, a window redraw isn't being asked for, so occasionally my palette does not get re-mapped when the window comes to front, or it doesn't get re-mapped by the OS when another window (e.g. a NeoDesk file window) comes to front.

Finding well-behaved patterns in ST application design seems to be an exercise in utter frustration...

-Thom


I can’t really imagine what the error looks like. Do you mind to do a small screen recording (shouldn’t be too hard to achieve in an emulator) and uploading this somewhere?

Regarding application design: maybe a look in other’s source code may help, e.g. Smurf or others like Phoenix.

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

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Fri Sep 28, 2018 8:18 pm

Yup, I will do one, shortly. I am attaching some handlers to events and will record once I've finished up.

-Thom

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

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Fri Sep 28, 2018 8:34 pm


User avatar
Cyprian
Atari God
Atari God
Posts: 1507
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Window refresh problems under Geneva/Neodesk

Postby Cyprian » Fri Sep 28, 2018 8:39 pm

tschak909 wrote:Also, how can I determine whether my window is selected or not?


try to listen Event_Multi messages like WM_TOPPED, WM_NEWTOP, WM_ONTOP, WM_UNTOPPED
http://toshyp.atari.org/en/008007.html
https://www.seasip.info/Gem/aesmsg.html
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

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

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Fri Sep 28, 2018 8:50 pm

Yup, I finally found those in the tos compendium...

What's the difference betwen TOPPED, NEWTOP, and ONTOP?

also, when I attach to those, my window borders don't seem to draw correctly, any longer, am guessing i'm not doing proper window lifecycle maintenance :(

-Thom

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

Re: Window refresh problems under Geneva/Neodesk

Postby wongck » Sat Sep 29, 2018 1:01 am

I have not seen your code, so not sure what you have done.
I am guessing that you may not have used a virtual workstation, and so your palette changes as it may be randomly using some random memory location as your virtual workstation settings.

I suggest that you look at Tim Oren professional GEM as it steps you on how to do a GEM program rather than you figure out how big program like Smuft or Pheonix from several MB of code ( would be good later after you grasp GEM windows ).
https://comradelaika.files.wordpress.co ... of_gem.pdf

Also the screen updates.... you need to do this entirely on your own. The OS will not update the part of overlapped windows when you top your window. So you need to redraw always your entire buffer. Sure it is slow, you need to optimise later when know which part needs updating, that the AES will tell you.
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

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

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Sat Sep 29, 2018 1:14 am

I am using windom, which does indeed do the v_openvwk for me. So I am indeed using a virtual workstation pointer.

But I am fast reaching a decision gate as to my redraw method, This is a terminal, and is, as a result, drawing based on the input stream.

So as I see it, I have two options for redraw, both of which really suck on the ST:

* I use vro_cpyfm after a draw operation, to copy to an off-screen MFDB. Essentially mallocing enough space for window_width*window_height*nplanes, and periodically copying what's on screen to this buffer, and subsequently vro_cpyfm''ing it back. This could take anywhere from 32K to 800K for the required buffer.

* I keep the input data stream and re-play it from the most recent screen clear, while this would be better, it would have two problems, (a) even though screen clear would clear the buffer, the potential buffer replay could be huge, e.g. if you're sitting at the main menu page, which has an updating clock, imagine leaving it for 24 hours, and then suddenly moving a window...

What the $#@%@ can I do? :(

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

Re: Window refresh problems under Geneva/Neodesk

Postby wongck » Sat Sep 29, 2018 1:18 am

IDK... I don't use Windom so IDK.
My guess is try running the Windom demo to see if it works for Geneva.

I would stick with standard GEM library that you know what's going on with.

I know it is a terminal. You mentioned you have a buffer in your post above, so you have to redraw your window based on that. Sorry that's GEM for you.

In any case, go over Tim Oren book, it is short and gives you more information on GEM programming that will be useful even if you use a library like Windom, EGEM, BIG or EasyGEM. The book talks about fundamentals.
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

mikro
Atari God
Atari God
Posts: 1733
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Window refresh problems under Geneva/Neodesk

Postby mikro » Sat Sep 29, 2018 8:18 am

wongck wrote:I suggest that you look at Tim Oren professional GEM as it steps you on how to do a GEM program

:cheers: If it wasn't for Tim Oren, there wouldn't be any mxPlay at all. Loved his tutorials, super clear and to the point.

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

Re: Window refresh problems under Geneva/Neodesk

Postby arf » Sat Sep 29, 2018 12:55 pm

wongck wrote:I have not seen your code, so not sure what you have done.
I suggest that you look at Tim Oren professional GEM as it steps you on how to do a GEM program rather than you figure out how big program like Smuft or Pheonix from several MB of code ( would be good later after you grasp GEM windows ).


I picked the two not out of random: Smurf because it does a full colour palette handling, and Phoenix because it’s kind of a reference implementation of "Vom Anfänger zum GEM-Profi" of Geiß&Geiß. Geiß&Geiß are to Germans what Oren is for the English speaking fan base: an easy good-to-read introduction to GEM programming.

And even it it’s multi MB sourcecode - the place where window handling is, isn’t megabytes of source code

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

Re: Window refresh problems under Geneva/Neodesk

Postby wongck » Sat Sep 29, 2018 1:03 pm

arf wrote:I picked the two not out of random: Smurf because it does a full colour palette handling, and Phoenix because it’s kind of a reference implementation of "Vom Anfänger zum GEM-Profi" of Geiß&Geiß. Geiß&Geiß are to Germans what Oren is for the English speaking fan base: an easy good-to-read introduction to GEM programming.

I am sure everyone here is trying to help, given the small number of us still around.
Yeap, those great programs and having released source codes for all to enjoy even more.
Great choices :thumbs:
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

User avatar
lp
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2357
Joined: Wed Nov 12, 2003 11:09 pm
Location: GFA Headquarters
Contact:

Re: Window refresh problems under Geneva/Neodesk

Postby lp » Sat Sep 29, 2018 2:46 pm

I certainly agree about Tim Oren, his tutorials are even good for non-C coders.

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

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Sat Sep 29, 2018 4:50 pm

So, my current redraw plan is to attempt a malloc of a memory area the size of the current display, and if it succeeds, to use that as a backing store, on redraw.

The thinking is that if you've got enough space for bigger than a 512x512 window, you've got enough space to hold a backing store, for it.

If it fails, no big deal, no redraw.

This is okay, because if you're running any resolution below 512x512, then the program is displaying in fullscreen and is always on top, obscuring what is underneath, and can't be moved..so..

I think given the unusual requirements for this program, that's an acceptable solution, if I can make the backing store work properly.

-Thom

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

Re: Window refresh problems under Geneva/Neodesk

Postby wongck » Sun Sep 30, 2018 3:42 am

OT...
So I saw one of your video on youtube (sound barely audible cranking to the max) trying to see how this thing works.
Seems like you are using serial protocol, and also used a software on Linux to convert TCP/IP to serial.
So do you need a modem for this?
What is the host IP address to use this? I am sure STING should also be able to connect via TCPIP.
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

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

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Sun Sep 30, 2018 4:16 am

yes, STING could be used. it's on my list to do an implementation that uses STING.

And yes, the majority of the terminals available use a modem emulator of some sort. :) I use tcpser in my own setup, (my fork of tcpser is here: http://github.com/tschak909/tcpser)

The website is http://www.irata.online/, which has the currently available terminals, as well as the connection instructions.

(the server is irata.online port 8005)

Right now, am trying to figure out how to read the radio buttons that are created from a windom FormWindBegin/Do/End... Creating a callback using their callback mechanism isn't working, so am tracing through the framework to see if I am sending the wrong type of object (probably)...

-Thom

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

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Sun Sep 30, 2018 5:29 pm

Actually, I have an idea...

Instead of using VDI calls to draw the window, I can have the AES do the work by creating user defined objects for my drawn primitives (line, dot, alpha, block erase, paint)...this would allow the AES to maintain the window in its rectangle list, and redraws would just work...

Is there a hard limit to how many objects AES can handle in its window tree?

-Thom

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

Re: Window refresh problems under Geneva/Neodesk

Postby arf » Sun Sep 30, 2018 6:42 pm

tschak909 wrote:Actually, I have an idea...

Instead of using VDI calls to draw the window, I can have the AES do the work by creating user defined objects for my drawn primitives (line, dot, alpha, block erase, paint)...this would allow the AES to maintain the window in its rectangle list, and redraws would just work...

Is there a hard limit to how many objects AES can handle in its window tree?

-Thom


Sorry, given that you want to support older (Single)TOS versions, this doesn’t sound like an excellent idea. I don’t know the limits of old TOS 1.x by heart but would expect these to be low. And I expect it to be slow, esp. without KAOS/MagiC/NVDI.

ThorstenOtto
Captain Atari
Captain Atari
Posts: 400
Joined: Sun Aug 03, 2014 5:54 pm

Re: Window refresh problems under Geneva/Neodesk

Postby ThorstenOtto » Mon Oct 01, 2018 12:50 am

tschak909 wrote:this would allow the AES to maintain the window in its rectangle list, and redraws would just work...


AES does not draw your window (only the frame elements like titlebar). You would still have do call objc_draw() on receive of a WM_REDRAW, and you would still have to to encapsulate that in wind_get(WF_FIRSTXYWH) and honor the clipping rectangle. So that idea will only make your redrawing slower, because you have to calll AES, which in turn calls your user callbacks, which then call the same VDI functions that you could have used at the very beginning.

Is there a hard limit to how many objects AES can handle in its window tree?


What window tree? Beside that there is no official limit on the number of objects in an object tree, but an OBJECT structure has 24 byte, so after (32768/24) = 1365 objects, addresses might become negative.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 762
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Window refresh problems under Geneva/Neodesk

Postby mfro » Mon Oct 01, 2018 5:13 am

I only peeked briefly into your code (and thus surely didn't understand everything) but you seem to ignore the fundamental rules of AES: you can't just draw something somewhere on the screen.

It's the AES that has control of the screen, not you.

With GEM AES, you almost never just draw something on your own. It's the AES that tell you to draw something in response to an event.
You do that in your event callback routines. When the event callbacks are called, you'll get the screen area the AES want to have redrawn (or initially drawn). You are supposed to set the drawing limits to the area the AES tells you (either by limiting yourself to the said area or by setting the clipping rectangle accordingly).

If other windows overlap your drawing window, you'll get not only one event, but several. One for each rectangle as a result of the overlap.

Code: Select all

                                                  +-----------------------------------+
                                                  |                                   |
     +--------------------------------------------|                                   |
     | 1111111111111111111111111111111111111111111|                                   |
     | 1111111111111111111111111111111111111111111|                                   |
     | 1111111111111111111111111111111111111111111+-----------------------------------+
     | 11111111111111111111111111111111111111111112222222222222|
     | 11111111111111111111111111111111111111111112222222222222|
     +---------------------------------------------------------+


To (re)draw one window, you might get several redraw events. In above example, one with the '1s' area and another one with the 2s (this is just a simple example, in complex overlap situations, you might get a whole lot of redraw events for a single window).

Consequence is: you always need to be prepared to repeatedly (re)draw arbitrary parts of your window.

There are several ways to do that:

  • draw into offscreeen bitmaps and blit them to the screen from there. This appears to be the most straightforward way, but is very limited in practice (as standard TOS doesn't support this out of the box)
  • always draw the whole window, but set the clipping rectangle to the area the AES request beforehand. This will limit visible output to the clipping rectangle (but will be slower than possible as you might find yourself "drawing the invisible" most of the time)
  • combine the two methods above: whenever the AES asks you to redraw an area, do that using the second method. As final action (before you give back control to the AES), blit away your on-screen result into your backbuffer. This is probably the fastest method, but you need to maintain a list of the current areas you have in your backbuffer (it also might contain "white" areas you haven't drawn so far)

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

Re: Window refresh problems under Geneva/Neodesk

Postby joska » Mon Oct 01, 2018 7:37 am

An additional tip: Only draw as a response to the WM_REDRAW message. Traverse the rectangle list (using wind_get) and redraw each rectangle but as mfro says do not draw outside this rectangle. If you need to initiate a redraw yourself you just send yourself a WM_REDRAW message. This way there is only one piece of code that handles redraws, which makes the code a lot simpler and safer.
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: 80
Joined: Mon Mar 26, 2018 9:29 pm

Re: Window refresh problems under Geneva/Neodesk

Postby tschak909 » Mon Oct 01, 2018 8:31 am

*facepalm*

I love how people don't bother to:

(a) read my code.
(b) take the time to actually read back through what I have been going through to get to this point, and the compromises I have had to take to even get this software to work on this machine.

yet, seem to have an abundance of information on how I am not adhering to a theoretical purity of design.

With that, I will take a deep breath, and try to explain, concluding with a practical plea.

Please read all of this:

I am writing a terminal program.

This is not a typical terminal program, in that you're essentially trying to display a window of scrolling text onto some sort of masked canvas.

It is more akin to something like a Tektronix 4010 terminal. There is no scrolling, and everything happens in the context of a single screen.

I understand the THEORY behind GEM's windowing system, but trying to fit the REALITY of what's happening with the PLATO bit-stream to make AES and VDI happy, is more difficult than would first appear.

Ideally, I would have _LOVED_ to work in this fashion:

* Byte comes in from I/O as a result of timer.
* Byte goes through protocol decoder
* a drawing event happens, which gets rendered to an off-screen buffer
* redraw events simply vro_cpyfm() from this offscreen buffer to the active screen, setting clipping as necessary, for as many rectangles as AES wants.
* process input from keyboard
* handle other application lifecycle events
* repeat.

But GEM, in its infinitely primitive wisdom, thinks that the world is a static one, where the entire state of a window can be completely reconstituted at any time upon request...

So I initially tried to implement a screen queue, a singly linked list of sorts, which would comprise a drawing operation and its associated state. Screen clears would dispose of the queue.

This worked (but there was a catch)... but I tried another idea, just save the terminal stream. Easier to implement, but both of these approaches had a glaring problem:

The terminal data is such that there are situations (which are not rare), such as games within the PLATO system which stay on a screen without clearing, but have a lot of data flying across, movement, animation, etc, all of which must be re-played to bring things back to a known state (i'll imply 'within a rectangle') There is, for example, a time of day clock which iterates every 5 seconds, on the menu pages of IRATA.ONLINE... If you leave the terminal session running for any length of time, and cause a complex redraw scenario (let's say you suddenly bring the window to the top of a whole stack of windows) This means potentially, multiple re-plays of the same state buffer, over and over (let's be hyperbolic and say, you leave it running for a week, that's a week's worth of state, being re-played, multiple times!), and this would happening WHILE there may be serial data coming in. It's a fornicating nightmare.

So yes, I completely understand what you're trying to say, I have no practical way to do it. I need a practical solution to these problems, and I can't just tell users to "install NVDI5 and be done with it." to get off-screen buffers, which should have been a part of VDI in the first place.

So with all of this in mind, I made a hard decision, I made the app full screen, made it so it stayed on top, and therefore I could guarantee that I could draw to the screen with minimal interference, and try to avoid the (VERY REAL) problems that would happen, otherwise.

So please, can you all understand that I have literally been trying to do it the right way, and the current way I have done it was me finally just saying "cluck it" and trying to get something that worked?

With this in mind, if someone were to reply, could you please reply with practical examples and approaches? I have released close to 10 of these terminal implementations, and have at least a dozen more currently being written (you can see the list on http://www.irata.online/), so please understand when I say, I AM HAVING TO PICK AND CHOOSE MY BATTLES CAREFULLY.

Everything I do is public, so if you can help make this terminal better, please, I could use the help. I am trying to produce something unique for every single retro-computing community, and really want to provide this software for everyone's benefit in this community.

*exhausted*
-Thom

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

Re: Window refresh problems under Geneva/Neodesk

Postby joska » Mon Oct 01, 2018 9:08 am

tschak909 wrote:So with all of this in mind, I made a hard decision, I made the app full screen, made it so it stayed on top, and therefore I could guarantee that I could draw to the screen with minimal interference, and try to avoid the (VERY REAL) problems that would happen, otherwise.


There is basically no difference between full screen and windowed mode, except that in windowed mode you'd have to be able to REdraw any part of the screen upon request from the window manager. From your description this is what you're struggling with - you don't have good algorithms/code that can replicate what's currently being displayed.

Yes, the fact that GEM in it's pure form have no concept of window CONTENT can be frustrating for a developer. You just have to deal with it.

tschak909 wrote:The terminal data is such that there are situations (which are not rare), such as games within the PLATO system which stay on a screen without clearing, but have a lot of data flying across, movement, animation, etc, all of which must be re-played to bring things back to a known state (i'll imply 'within a rectangle') There is, for example, a time of day clock which iterates every 5 seconds, on the menu pages of IRATA.ONLINE... If you leave the terminal session running for any length of time, and cause a complex redraw scenario (let's say you suddenly bring the window to the top of a whole stack of windows) This means potentially, multiple re-plays of the same state buffer, over and over (let's be hyperbolic and say, you leave it running for a week, that's a week's worth of state, being re-played, multiple times!), and this would happening WHILE there may be serial data coming in.


Two ways to solve this:
1. Offscreen bitmaps, either using NVDI or by implementing your own drawing routines and draw to a monochrome bitmap.
2. When adding a new object to the list, remove any object(s) that is being totally overwritten by it. You already know the location and size for all objects so this should not be a problem. To further refine this you can associate a clipping rectangle with each object, and adjust this when an object is being partially overwritten by a new object. This should remove any flickering when "replaying" the object list.
Jo Even

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

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 762
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Window refresh problems under Geneva/Neodesk

Postby mfro » Mon Oct 01, 2018 12:03 pm

tschak909 wrote:With this in mind, if someone were to reply, could you please reply with practical examples and approaches?

...

*exhausted*
-Thom


Dear *exhausted* Thom,

it appears your request for offscreen rendering is a valid one for your specific use case (although its hard to imagine that the original CDC implementation would have allowed accumulating days and weeks of drawing state on the terminal side only without buffering the same on the server to be able to replay it - e.g. if the connection went lost).

I think I already posted this, but (just in case) here: https://github.com/mfro0/libcmini-examp ... ster/bench you'll find a rudimentary implementation of an offscreen renderer that supports drawing horizontal lines, arbitrary lines, circles and filled circles (the VDI basic drawing functions) for the Atari standard resolutions (1, 2, 4 and 8 bit interleaved plane modes and 16 bit "true colour" modes). Using this (and the device specific VDI raster copy functions), you can draw into your own offscreen buffer (device specific format) and blit the result to the screen.

Beware that this covers all the basic Atari screen modes, but will not work on e.g. graphics cards of PC offspring that use linear framebuffer palette modes (like 256 colour VGA) and other "exotic" hardware (linear framebuffer palette modes should be trivial to implement, however).

Good Luck,
Markus

ThorstenOtto
Captain Atari
Captain Atari
Posts: 400
Joined: Sun Aug 03, 2014 5:54 pm

Re: Window refresh problems under Geneva/Neodesk

Postby ThorstenOtto » Mon Oct 01, 2018 5:18 pm

joska wrote:Yes, the fact that GEM in it's pure form have no concept of window CONTENT can be frustrating for a developer. You just have to deal with it.


Actually, this is the same concept as eg. in X or Win32. The system does not care about your window contents, you have to redraw it yourself. Main difference is only that in GEM, you have to walk the rectangle list yourself, while in other systems you just get several redraw messages, and the window manager takes care that you don't write into foreign windows. Also, on other systems there is always a way to create a offscreen buffer you can draw into instead.

Two ways to solve this:
1. Offscreen bitmaps, either using NVDI or by implementing your own drawing routines and draw to a monochrome bitmap.


I think that's the way to go. For a start, you could just require NVDI being present, and exit if is not available. Most users will have it, anyway. Later, if you want, you can make up your own drawing routines.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 4 guests