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.