Hi there, I've been thinking a bit more about what I think I can setup for you once we add more functions to the graphics drivers. That is, I think I know how to do it for all nVidia cards. ->I am already setting up the scaled_filtered_blit function. We should add support for that function to work with offscreen (but on card memory) buffers, this function can colorspace convert from 8bit (NV10 and up), 15,16,32 and B_YCbCr422 and B_YUV422 colorspaces (all cards) to RGB15,16 and 32: maybe also to RGB8 (NV10 and up). ->Maybe it's possible to setup some form of transparant blit: I don't know yet. ->I _do_ know (since my 3D attempts) that I can get going on all nVidia cards the blit function for offscreen bitmaps: but they have to be on the grapics mem (but may be offscreen for sure!) You should expect this: ->source and dest must be in same colorspace (unless you would use the scaled_fitlered_blit version). ->the source has a starting adress (offset from cardRAM), but may need to be aligned to a page_size defined by the nVidia hardware (probably something like 16 bytes or so, but it differs per manufacturor so to speak) ->The source has a width and height ->the source may have a slopspace: like it is also with framebuffers (the desktop in for exampe 800x600 on older cards in B_CMAP8 (don't forget about that ;-) is a good example. Also overlay bitmaps have the slopspace thing as you know. ->Forget about what I set about blitting from main mem: I don't really dare to say anything about that yet. Also when we are going to doublebuffer windows offscreen It probably a bad idea to keep them in main mem due to the large busload you'll create. ->What I want from the system is support for the page_size, and a fullblown memory manager for managing all these bitmaps. The driver should not have to think about that. The manager must also support the overlay bitmaps. I have things like: user/system creates unequally sized buffers #1, 2 and 3, then deletes 2, and then creates #4 bigger than 2. What about the gap the old #2 represents? This stuff should be the systems problem I'd say. ->The offscreen standard blit works quite simple: I need to issue a 2D_SET_SURFACE command inside the driver for each blit coming from different sources. This command is quite quick as it does not involve data transfer, and issuing it makes me very flexible :-). ->If you think it's perfectly possible to do the transparant window borders and dragging using this scenario, then go for it (after R1). ->If this includes a guaranteed flicker-free cursor and it's dragging bitmap: we can indeed forget about the hardware cursor. If not, I suggest adding support for RGBA32 cursors in the interface, as modern nvidia cards (all gf at least) can do that. Remember: this is a overlay as well. That is, you can use the RGBA32 cursor independant of the colorspace set for the visible workspace. -- Note: While the current 2D features only work on colors (not alpha) (RGB15 and 32 only of course), I think I know since my very first 3D attempts that I can include the alpha channel for the commands. This I cannot guarantee 100% yet though. -- conclusion: all stuff I know for sure except: -alpha channel including in commands (say estimate 75% chance I can do it) -blitting from main mem (say estimate 10% chance I can do it). =========== Hope this will be enough to think about what direction to go. All things described are 2D commands in fact, so independant of missing 3D engine (init) info. And as it's been said that (what OS was that?) already has support for offscreen bitmaps for window double buffering (so composing desktop fully on card as you call it AFAICT) for ATI cards that means we have ATI and nVidia covered. Greetings :-) Rudolf.