Two questions about C2DGraphics

[JoeStrout]

I'm studying the C2DGraphics class, and have some questions...

The UpdateDisplay method does one of two things, depending on the m_bVSync flag:

• If set, it does a fast page flip by just calling SetVirtualOffset on the frame buffer, and then waits for a vsync.
• If not set, it does a memcpy from the offscreen buffer to the on-screen buffer, without waiting for vsync.

1. What if I want to do the fast page-flip, but not wait for vsync (because, for example, I already wait for vsync elsewhere in my kernel)?

2. And for that matter: why do we wait for vsync after flipping the page (calling SetVirtualOffset)? If UpdateDisplay happens to be called well before the vsync signal, wouldn't it put the screen in a state where it changes while drawing (causing tearing)? Seems like we should vsync before flipping the page.

[rsta2]

This class has been provided by Stephane Damo and unfortunately I do not know, why he waits for V-sync after re-setting the virtual offset. Honestly I never thought about it. But you may be right and it should wait before. As a solution I could add a boolean parameter bDoNotWaitForVSync to UpdateDisplay() and a method, which returns a pointer to the instance of CBcmFrameBuffer inside C2DGraphics. You could wait everywhere for VSync then, before or after or never. What do you think?

[JoeStrout]

Perhaps. There's already the m_bVSync flag on the class; it's just that it's doing double duty. A cleaner fix might be to add an additional flag, something like m_bPageFlip to control whether we do the virtual-offset trick or instead just do a memcpy from the offscreen buffer to the onscreen one.

One other thing I've been thinking about since last night: right now, if using the page-flip method, you run into trouble if you do just occasional drawing (rather than redrawing everything every frame). I assume UpdateDisplay() is called every method, giving your app a nice 60 Hz update loop, but based on application logic, we just occasionally draw something new to the existing state of the display. For example, maybe it's a drawing app, and the user can click and drag with the mouse to scribble.

In this case, the new line is drawn to the backbuffer on frame N; then flipped to the screen on frame N+1, and the new backbuffer doesn't have that line. Then the next segment of the line is drawn on frame N+1, which gets flipped to the screen on frame N+2, which shows the missing line segment. Basically, when our drawing is extended over multiple frames like this, we end up with two partial (and both incorrect) versions of the drawing, alternating at 60 Hz.

Note that this doesn't happen if we don't use the page-flip method; in that case, UpdateDisplay does a memcpy from backbuffer to display buffer, and at that point both buffers are identical. So you can then do more drawing to the backbuffer, and it's fine.

So! My suggestion here would be to add a parameter to UpdateDisplay along the lines of bSyncBuffers, default false. This has no effect if not using the page-flip method. But when you are using the page-flip method, if bSyncBuffers is true, then we do an additional memcpy so that, after the flip, both buffers are identical and you can do more drawing.

Hmm, but now that I think about it, in this case there is probably no benefit to using the virtual offset at all. I guess in this situation you could just set m_bVSync to true and m_bPageFlip to false, so it waits for the vsync but just copies the backbuffer to the screen.

[rsta2]

I'm probably not the right person for discussion about, how to develop a GUI without a framework from scratch. I haven't done this yet.

I think, the C2DGraphics class is a side product from developing a GUI from scratch for a commercial product, which has been done by Stephane Damo. I think, it is built for exactly the model, you have described: Redrawing the screen at 60 frames per second. I heard, many applications are using it.

There may be other models, which are more suited for a specific type of an application. The good thing about open source is, that one can take the existing source code and modify it to fit for a specific model.

C2DGraphics is now in Circle for a while, and I cannot do changes to it, which break the model or the API. I could do small changes, which extend the range of application, but the default function must remain.

So if you have modifications for Circle in this context, how about proving it with a small test program, and sending a pull request for this modification, which appends the test program? Then I can check, that it's useful and apply the changes.

[JoeStrout]

That's very fair. I will experiment on my end and if I think I have a nice improvement that won't break existing code, I'll submit a PR.