The window of phclock is not on top and it was a long time it was not on top believe me, the only difference between the vignette and the original window (there is some seconds) is link to the time to display the vignette and to do the snapshot (because I not update the vignette but I could).

back to composite desktop: I really have no clue how VDI draw primitives+widgets on screen. Currently I trying to find out by reading various documentation on net.

as far as I understand, VDI see only one bitmap: e.g. 640x480 pixel screen size. and all drawings is only possible directly in this part of memory that hold 640x480 screen. right?

1) so first thing would be to force that every initialized window have it's own memory and to make VDI use it for drawing- window would need to redraw only if user change something or if window is resized.

2) you need some composite process that will draw all windows to screen- all information about window size or position are already there.

btw how PCI TV Card for Milan computer is implemented? Does it move entire frame buffer from TV card to onscreen Video memory 24 times per second (skipping GEM window - e.g. TV is always on top)?

Maybe. But since you're writing the AES you can pretty easily do it like this:

1. If a window's rectangle list only contain one rectangle, and this rectangle equals the window's work area, it's completely visible and you don't need a backup of it's contents. So thumbnails (or backgrounds for window "composing") can be created when required.

2. When a window's rectangle list changes from the state in (1) to a state where there's either multiple rectangles or parts of the window is outside the screen, you save a copy of it's work area *before* you actually does the redraw/send redraw events. So you have a backup from the last time the window's work area was completely visible.

3. When your taskbar asks the AES for a thumbnail (if that's how you do it), the AES decides if it can copy the current window work area or use a backup.

calimero wrote:as far as I understand, VDI see only one bitmap: e.g. 640x480 pixel screen size. and all drawings is only possible directly in this part of memory that hold 640x480 screen. right?

Yes and no. NVDI - and TOS VDI with "Enhancer" running - can draw to any number of bitmaps. But the AES and AES applications draws only directly to the screen.

calimero wrote:1) so first thing would be to force that every initialized window have it's own memory and to make VDI use it for drawing- window would need to redraw only if user change something or if window is resized.

It can't work. There is no connection between VDI workstations and window handles. So the VDI (or AES) can't possibly know which window each requested VDI workstation is intended for. Even worse, many (most?) applications would probably use the same workstation for multiple windows.

If you want to do something like this you have to change the way AES application works. The AES must atleast request and assign a VDI workstation (or preferably an offscreen bitmap) to each created window. The application must be restricted to draw to this workstation exclusively. Then the AES can blit the offscreen bitmap to the actual screen when any changes occurs, and it can use transparency (or any other desired effect) when doing so.

This approach will only work for new applications specifically written for this. And these won't work with anything else than this new AES. Considering how few apps are written for GEM these days this just won't happen. It should have happened 30 years ago, but at that time the VDI/GSX didn't know about offscreen bitmaps.

calimero wrote:as far as I understand, VDI see only one bitmap: e.g. 640x480 pixel screen size. and all drawings is only possible directly in this part of memory that hold 640x480 screen. right?

Yes and no. NVDI - and TOS VDI with "Enhancer" running - can draw to any number of bitmaps. But the AES and AES applications draws only directly to the screen.

calimero wrote:1) so first thing would be to force that every initialized window have it's own memory and to make VDI use it for drawing- window would need to redraw only if user change something or if window is resized.

It can't work. There is no connection between VDI workstations and window handles. So the VDI (or AES) can't possibly know which window each requested VDI workstation is intended for. Even worse, many (most?) applications would probably use the same workstation for multiple windows.

If you want to do something like this you have to change the way AES application works. The AES must atleast request and assign a VDI workstation (or preferably an offscreen bitmap) to each created window. The application must be restricted to draw to this workstation exclusively. Then the AES can blit the offscreen bitmap to the actual screen when any changes occurs, and it can use transparency (or any other desired effect) when doing so.

This approach will only work for new applications specifically written for this. And these won't work with anything else than this new AES. Considering how few apps are written for GEM these days this just won't happen. It should have happened 30 years ago, but at that time the VDI/GSX didn't know about offscreen bitmaps.

Hello

I was agree with you up to some months ago, but in fact what calimero ask is near possible even with old GEM application not write for a new aes and if this applications not do exotic operations (most of application running with fVDI in window should work) if VDI is partially rewrite and work with AES, the problem is AES and VDI are today fully different. There is not so work but with new video card I think it need more work. Nothing impossible.

I haven't been following this discussion very closely, but I wanted to mention that even if these modern features could be implemented somehow, they wouldn't bring us new applications. Honestly, who uses an Atari for his email or to browse the web or edit text documents these days? I would love to be able to move some of my Linux PC workload onto my FireBee, but I don't see it happening anytime soon. What's the point of a compositing desktop or whatever if it's to run decades old software? I'll choose a decent email client over transparent windows any day.

^well, they are two separated issue (composite desktop and new applications). e.g. anti aliasing of font in MyAES is great feature and it is tied to OS level! (although I can not see it properly since I use RGB monitor but it will change when super videl arrives )

I ask my self what would be benefit of composite desktop. (if it is technical possible)

OL wrote:I was agree with you up to some months ago, but in fact what calimero ask is near possible even with old GEM application not write for a new aes and if this applications not do exotic operations (most of application running with fVDI in window should work) if VDI is partially rewrite and work with AES, the problem is AES and VDI are today fully different.

I'm very curious about how you plan to solve this. As you say, the AES and VDI are completely separate. When an application requests a handle from VDI it can use this handle to draw anywhere on the screen. The AES is just another VDI client, drawing it's objects/window frames/desktop etc on the same screen as the other VDI clients.

But you got me thinking. You are right, it could be possible without changing the way AES clients works:

The AES must monitor all drawing operations, or maybe the other way around - the VDI must know about the window rectangle lists. Then it's possible to determine which window the individual drawing operations targets. The VDI can then redirect the drawing operations to individual bitmaps, one for each window. And if each window always has a single rectangle list (the same as the work area) each window will always be fully drawn even if they really overlap.

This will require a graphics card with lots of memory to work reasonably fast on real hardware. Then all the buffers can be kept on the graphics card, and the graphics card itself can blit the window bitmaps to the actual screen.

jfl wrote:I haven't been following this discussion very closely, but I wanted to mention that even if these modern features could be implemented somehow, they wouldn't bring us new applications. Honestly, who uses an Atari for his email or to browse the web or edit text documents these days? I would love to be able to move some of my Linux PC workload onto my FireBee, but I don't see it happening anytime soon. What's the point of a compositing desktop or whatever if it's to run decades old software? I'll choose a decent email client over transparent windows any day.

When you write software for free you do whatever you find more interesting.

OL wrote:I was agree with you up to some months ago, but in fact what calimero ask is near possible even with old GEM application not write for a new aes and if this applications not do exotic operations (most of application running with fVDI in window should work) if VDI is partially rewrite and work with AES, the problem is AES and VDI are today fully different.

I'm very curious about how you plan to solve this. As you say, the AES and VDI are completely separate. When an application requests a handle from VDI it can use this handle to draw anywhere on the screen. The AES is just another VDI client, drawing it's objects/window frames/desktop etc on the same screen as the other VDI clients.

But you got me thinking. You are right, it could be possible without changing the way AES clients works:

The AES must monitor all drawing operations, or maybe the other way around - the VDI must know about the window rectangle lists. Then it's possible to determine which window the individual drawing operations targets. The VDI can then redirect the drawing operations to individual bitmaps, one for each window. And if each window always has a single rectangle list (the same as the work area) each window will always be fully drawn even if they really overlap.

This will require a graphics card with lots of memory to work reasonably fast on real hardware. Then all the buffers can be kept on the graphics card, and the graphics card itself can blit the window bitmaps to the actual screen.

You have all understand! And I know it could work because I'm able to correctly see my bitmap on the new feature I have implemented in MyAES, in fact if I could said to VDI what it should do this will be very easy the work have already done for a big part.

jfl wrote:I haven't been following this discussion very closely, but I wanted to mention that even if these modern features could be implemented somehow, they wouldn't bring us new applications. Honestly, who uses an Atari for his email or to browse the web or edit text documents these days? I would love to be able to move some of my Linux PC workload onto my FireBee, but I don't see it happening anytime soon. What's the point of a compositing desktop or whatever if it's to run decades old software? I'll choose a decent email client over transparent windows any day.

When you write software for free you do whatever you find more interesting.

Thanks, bu I know that. I respect any person coding for this platform, and particularly Olivier, who pushes the envelop with his AES. My reaction was more about the discussion itself than the coding. It looks like some people are waiting for features that are available on other platforms. To do what? Stare at old apps bordered by shiny new widgets? Well, I guess I better just shut up because I don't get it.

^ I also wondered what we could do with new video hardware (supervidel) - all hardware premises will be there so I wonder if it is possible to get composite desktop out of 30 years old GEM.

For Microsoft, it took five years to achieve this with 10x more GPU power than on e.g. linux or mac os x. To be clear: I am totally astonished with all achivement on atari today. When I look at all what we have today on atari (especial consider ultra small userbase!) I am 100% sure that my father pick right platform in 1986. and that I grow up in utopia land of computer world. It is imposible how atari is uptodate in some area today!

Regarding composite desktop, I am curious how could it be achived and what benefits we would get from it. I really appreciate responses from joska and olivier.

Br, Milan

Last edited by calimero on Tue Jan 29, 2013 9:01 am, edited 1 time in total.