Talk:Framebuffer

Frame buffer

This and frame buffer should be merged. Should we keep the title with space or without? --Brion 07:23 Nov 23, 2002 (UTC)

This now seems to have been done. StuartBrady 22:42, 11 January 2006 (UTC)[reply]

Definition of Framebuffer

This page is just plain wrong. A framebuffer is a memory-driven display device. I'll see to adopting this article and updating it. Jbanes 18:11, 11 January 2006 (UTC)[reply]

I'm not so sure - I think a framebuffer is a memory buffer containing a frame. As for your adoption of the article, thanks very much! StuartBrady 22:14, 11 January 2006 (UTC)[reply]

Nope. Read the PDFs under "external links". A framebuffer is a device that drives a display from pixel memory. The memory itself isn't the framebuffer, though it is a critical (and defining) component. This distinction has sort of been blurred in many people's minds over time with the introduction of Virtual framebuffers such as Xvfb and the Linux Framebuffer device. However, you'll note that the documentation for both of these states that the software is emulating a device, not just providing a backbuffer. Jbanes 04:38, 12 January 2006 (UTC)[reply]

Quoting from Digital Paint Systems: An Anecdotal and Historical Overview : "A frame buffer is nothing more than a piece of computer memory with a means for viewing what it holds." However, I accept that virtual framebuffers don't count as true framebuffers (that's why they're "virtual"). StuartBrady 14:34, 12 January 2006 (UTC)[reply]

Precisely. Without the "means for viewing what it holds", it's not a framebuffer. The "virtual" framebuffers emulate a real device in much the same way that virtual memory emulates a real memory device. Jbanes 14:52, 12 January 2006 (UTC)[reply]

Right. I agree with that. As far as I can tell, though, a CRT controller is not a component of a framebuffer. Neither is a texture-mapper, or texture memory. The framebuffer is just the memory which is used to drive the display device. StuartBrady 15:24, 12 January 2006 (UTC)[reply]

Exactly. In 3D cards the texture memory feeds into the texture-mapper which writes the results into the framebuffer, which is then what we see on the screen. Sort of.

This is complicated by two factors that I can think of. The first is that a video overlay device might modify part of the video signal. This is commonly how the mouse cursor is implemented. The second is that some 3D cards run the video signal through filters to perform various effects. IIRC, 3DFX added hardware to one of their Voodoo cards that blurred the signal a bit to make it appear as if the screen were anti-aliased. It was a cute trick, but it meant that the "real-time anti-aliasing" couldn't be shown on screen captures. Jbanes 15:58, 12 January 2006 (UTC)[reply]

Can I just confirm, before I edit the article: you'd agree that a framebuffer is just memory with a special purpose? (I.e. it's mapped to the video output.) BTW, interesting point about the real-time anti-aliasing! StuartBrady 17:16, 12 January 2006 (UTC)[reply]

If by special purpose you mean that it's memory coupled with a display output, then yes. The two together form a complete framebuffer. Jbanes 18:11, 12 January 2006 (UTC)[reply]

~~I told you what I meant by special purpose, in brackets. I'm still not convinced. I'm sorry to complain, but I'm not getting anywhere here, so I give in. StuartBrady 19:48, 12 January 2006 (UTC)~~[reply]

I really shouldn't have said that. I'm sorry. I think you're in agreement with me, but I'm not sure. I'm saying that a framebuffer is memory coupled with a display output, but does not include that display output. This is what all the definitions I've been able to find say. If we don't agree, we should seek some means for resolving the dispute. It seems as though you thought that I was arguing that any memory containing pixel data counts as a framebuffer. I was not, as that would be preposterous. StuartBrady 20:28, 12 January 2006 (UTC)[reply]

Video RAM

Perhaps this should be merged into Video RAM? Or perhaps not? What do you think? StuartBrady 22:42, 11 January 2006 (UTC)[reply]

I personally thing that Video RAM should be expanded to cover the details of Video RAM in the various architectures of video cards. A framebuffer is only one example of what Video RAM is used for in a modern video card, thus making the topic much more complex. In addition, a dicussion of memory types and configurations (such as DRAM and VRAM) is pertinent to a Video RAM article, but not to a discussion of framebuffers. Jbanes

Agreed, but that wasn't what I was suggesting. StuartBrady 17:24, 12 January 2006 (UTC)[reply]

I probably wasn't clear. No, I don't think they should be merged. I think that the two topics each contain a lot of independent points that should be explored separately. The original request to merge was added at a point when the page claimed that a framebuffer was memory. In all reality a framebuffer is a device that consists of memory coupled with an output device, and not just Video Memory. It's important to note, however, that a framebuffer only uses pixel data. Video Memory, OTOH, may hold much more than a framebuffer. Information such as textures, GPU programs, backbuffers, and vertex lists also tend to share Video RAM with the framebuffer in a modern graphics card. When I'm done with this article, I may consider adopting the Video RAM article to add this info. That being said, perhaps it makes sense to merge Video RAM with the "Graphics Card" article? Jbanes 18:24, 12 January 2006 (UTC)[reply]

Request for Info

This is a laundry list of info that would be helpful in producing a complete article.

Details on Joan Miller's device. The only thing I have to go on is that it was a 3-Bit framebuffer. I have no info on the signal it produced, the resolution of the pixels, its architecture, or even if it produced a television signal. (For all I know, it might have driven a custom display.) All the citations I have point to a personal communication from Miller. I haven't been able to track this communication down.

Information on other framebuffer experiments would be nice to have.