Hi, Although a bit late, I want to make a few notes about the subject. > > (For dragging things, I think we can use the HW overlays if > > available - > > would spear us a lot of trouble.) > > Yes, but let's think about how to make this work without any changes > to the > driver API. Because I wouldn't know how to implement those. :-) If > you do, be > my guest!! notes: - there is only _one_ overlay engine if you are talking about the engine we use for video. -if overlayed video is running, you can't do your transparancy thing -you can only do _one_ transparancy thing at a time -note that the overlay engine has no target in RAM, it just sends its output to the monitor (directly!, so DAC) -I think there's a contradiction here: 1. Haiku doesn't want to use hardware cursors (AFAIK) because 'these days it can be done perfectly using other means'. Note here that the cursor hardware _is_ a hardware overlay especially created for this goal. 2. you want to do transparancy drawing using hardware overlay. So cursor (is example) gets drawn with video overlay engine. Eh: that cursor had it's own specialized engine! ---------- AGP bus and transfers. 1. CPU does write over bus: uses PCI transfers and FW if available 2. CPU reads over bus: uses PCI transfers. Note that the actual speed is just 1/10th of PCI speed because graphics hardware has fixed verly low priority for this type of transfer. 3. GPU does reads over bus (alternate solution for 1.) uses AGP transfers 4. GPU does writes over bus (alternate solution for 2.). THIS DOES NOT EXIST. Apart from the 'TurboCache' technology nVidia 'invented' for the GeForce 6200 TC series of GPU's (and of course ATI has it's own 'counterpart'). additional remarks: PCI + FW == AGP speed wise. (more or less) FW is troublesome on some hardware (almost all ATI cards AFAIK!) FW is not always supported. FW requires no additional specs. AGP transfers (so by GPU) require additional specs. Although I have it going for the command buffer I still never tested for it for actual blit functions (transferring a bitmap _litterally_ (so in same colorspace as frontbuffer) over the bus. My guess is though that it would be simple to get it going on _all_ nVidia cards. (can be a 2D command, the 3D version would be troublesome to say the least;-) PCIe. PCIe writes and reads should be equally fast for CPU initiated reads/ writes, and GPU initiated reads/writes. Unfortunately the write-by-GPU does not exist (as mentioned above) and the read-by-CPU keeps being 1/10th of old PCI speed due to thing mentioned above. General rule: prevent/minimize any type of read from graphics card RAM! ------------ graphics memory manager: Would be nice to have. For all cardRAM. It should know where the cursor sits (if used), and the visible framebuffer, the overlay bitmaps etc. There should be just one manager for all mem I'd say. A driver BTW may need to create some private bitmaps as well. There should be room for it to ask that from the memory manager. (double buffering for TVout comes to mind as it would need to be done on matrox G450/550 for Desktop TVout. But I guess more reasons could be found for such a bitmap. Rudolf.