OSDev.org

Hi,
I am confused, how graphical views are scrolled (up, down, right, left)? Does the view contains a back buffer for storing the off screen contents ? Or something else? I am seeking for good explanations.

Thanks in advance

Hi,

I think in this case, when you mention a "back buffer", what you are actually referring to is a viewport.

For any kind of good explanation, more details are needed. What hardware? What video mode (LFB / VGA Text / other)?

For example, my console uses any hardware supported resolution with a LFB and I simply use memcpy's to scroll text - inefficient but good enough for a debug kernel. I expect that when implementing something for user mode, I'll want proper buffering and so on. Perhaps your post is referring more to graphics than text though?

More details please.

Cheers,
Adam

EDIT: I've just seen in your title that you're looking for explanations on a GUI. It sounds more than ever like we're talking about viewports, then. In which case I imagine you are wanting information on per-application buffers and viewports. Is that correct?

AJ wrote:Hi,

I think in this case, when you mention a "back buffer", what you are actually referring to is a viewport.

For any kind of good explanation, more details are needed. What hardware? What video mode (LFB / VGA Text / other)?

For example, my console uses any hardware supported resolution with a LFB and I simply use memcpy's to scroll text - inefficient but good enough for a debug kernel. I expect that when implementing something for user mode, I'll want proper buffering and so on. Perhaps your post is referring more to graphics than text though?

More details please.

Cheers,
Adam

Hi,

I am referring to graphics, like list view scrolling, rich text editor scrolling. How can I implement scrolling? Do viewport contains back buffer for storing off-screen contents? How scrolling works in graphics? Not in text!!

I am using GOP & VMware SVGA for graphics rendering.

You could draw the contents clipped to the view boundaries. When the view scrolls, draw contents to fill the uncovered area.

Or, you could draw the contents to a back buffer. When the view scrolls, display different parts of the back buffer.

Or, you could combine both options. Use a back buffer that's bigger than the view but smaller than the contents. Draw the contents clipped to the buffer boundaries. When the view scrolls, discard the buffer contents that go further away and reuse that part of the buffer to draw contents that are closer to the view. (I think web browsers do this.)

Octocontrabass wrote:You could draw the contents clipped to the view boundaries. When the view scrolls, draw contents to fill the uncovered area.

Or, you could draw the contents to a back buffer. When the view scrolls, display different parts of the back buffer.

Or, you could combine both options. Use a back buffer that's bigger than the view but smaller than the contents. Draw the contents clipped to the buffer boundaries. When the view scrolls, discard the buffer contents that go further away and reuse that part of the buffer to draw contents that are closer to the view. (I think web browsers do this.)

Ok I'll try to implement this, thank you!!

For item lists i first compute the total item height and viewport height to get the scroll buttons height, and start drawing the first item based on the scroll button position. So you always have full items displayed and scroll on per item bases.

For more complex content you might want to either draw everything in a back buffer and scroll / clip on the viewport. For static content its ok. For dynamic content it can be more wasteful.

Or determine which item rect intersect with the viewable part and draw only this with a small offset from the top of viewable items to the top of the viewport, for scrolling at pixel granulosity.

h0bby1 wrote:For item lists i first compute the total item height and viewport height to get the scroll buttons height, and start drawing the first item based on the scroll button position. So you always have full items displayed and scroll on per item bases.

For more complex content you might want to either draw everything in a back buffer and scroll / clip on the viewport. For static content its ok. For dynamic content it can be more wasteful.

Or determine which item rect intersect with the viewable part and draw only this with a small offset from the top of viewable items to the top of the viewport, for scrolling at pixel granulosity.

Hi, thank you so much for your reply. What do you do for text items like rich text edit or any gui control that contains text ? Do you draw it to back buffer? And what should be the size of back buffer ? I think the size should be equal to screen size! Am I right?

Thanks in advance

Kamal123 wrote:

h0bby1 wrote:For item lists i first compute the total item height and viewport height to get the scroll buttons height, and start drawing the first item based on the scroll button position. So you always have full items displayed and scroll on per item bases.

For more complex content you might want to either draw everything in a back buffer and scroll / clip on the viewport. For static content its ok. For dynamic content it can be more wasteful.

Or determine which item rect intersect with the viewable part and draw only this with a small offset from the top of viewable items to the top of the viewport, for scrolling at pixel granulosity.

Hi, thank you so much for your reply. What do you do for text items like rich text edit or any gui control that contains text ? Do you draw it to back buffer? And what should be the size of back buffer ? I think the size should be equal to screen size! Am I right?

Thanks in advance

For the moment my system is made with containers that are like windows that contain an object graph, application add controls to the object graph, and the rendering thread loops through containers and deal with clipping/ scrolling to know which controls needs to be rendered where.

Its made to be recursive to have child containers or controls that control the clipping and position at each steps.

In theory it can have a container inside of a scrolled view that contain another scroller etc.

But its completely work in progess im not sure its the best model