Here's a radical thought: why read the frame buffer at all when using Render? What if Render did not render directly to the frame buffer but rather rendered to main memory, with the results being copied "regularly" to the screen?
I am not thinking of this being specific to Render, but maybe a new extension, something like the Backing Store extension which can be turned on for selected windows. When enabled all drawing is to main memory, like it would be for completely obscured windows with Backing Store. This would be a useful extension in itself: it would make flicker-free updating of windows easy. Currently to do the same thing you have to render everything to a pixmap instead of a window then CopyArea the pixmap to the screen. This extension could even know what parts of the window are "dirty" (have been drawn to) and could blt only those e.g. using some sort of space partitioning, or whatever VNC uses. When sitting on top of this extension Render's reads would be from main memory and the whole issue of the speed of reading the frame buffer would be avoided. True you would be giving up all hardware acceleration on such windows so this approach may be overkill for most applications. In many environments though it could be useful, for example doing graphics on a (roughly) 640 x 480 TV screen. There you want to draw off-screen so that updates to the screen happen "at once" and are flicker-free. There are few pixels so hardware acceleration doesn't matter that much, although you would probably want to use screen hardware to scroll parts of the screen; VNC does something like this I believe. In these environments you may want to globally enable off-screen drawing and tell the X server to always draw off-screen, for all windows. Note that unlike the Backing Store extension there would be no attempt to retain pixels that are obscured: there is a single pixmap the size of the screen that always has a copy of the pixels on the screen. This extension could also be useful on PDA's if X is used on them. This support would be a form of double buffering, and maybe the double buffer extension already does this. Or maybe there is already some sort of "shadow frame buffer" support in XFree86. If what I'm suggesting already exists, pardon my ignorance. If it doesn't exist maybe it should. Peter Kaczowka Keith Packard wrote: > Around 14 o'clock on Aug 26, Juliusz Chroboczek wrote: > > > What happens to cached memory? Is it possible to map the same memory > > multiple times with different memory types? > > The MTRRs take physical addresses, and I believe the result of creating > MTRRs with overlapping ranges is to use the most conservative access mode. > > What I don't know is if we could set the frame buffer to write-back and > add suitable cache flush instructions when switching from accelerated to > unaccelerated rendering. The trick is to make sure that any memory > modifyied by the accelerator is flushed from the processor cache. Given > the expected use of software for much of the Render extension, it might be > interesting to investigate this possibility. > > Keith Packard XFree86 Core Team HP Cambridge Research Lab > > _______________________________________________ > Render mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/render _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
