RenderBuffer content scrolling

Registered by Paul "LeoNerd" Evans

For Windows to contain a long-lived RenderBuffer storage of their contents, this storage needs to have scrolling operations applied to it when the Window itself gets scrolled.

Blueprint information

Status:
Complete
Approver:
Paul "LeoNerd" Evans
Priority:
Medium
Drafter:
Paul "LeoNerd" Evans
Direction:
Approved
Assignee:
None
Definition:
Approved
Series goal:
Accepted for trunk
Implementation:
Implemented
Milestone target:
milestone icon v0.2
Started by
Paul "LeoNerd" Evans
Completed by
Paul "LeoNerd" Evans

Related branches

Sprints

Whiteboard

Need some thoughts about API for what the scroll operation would look like. For existing precedent there's only really one, being

    bool tickit_term_scrollrect(TickitTerm *tt, TickitRect rect, int downward, int rightward);

This might suggest a function of:

    void tickit_renderbuffer_scrollrect(TickitRenderBuffer *rb, TickitRect rect, int downward, int rightward);

(it doesn't need to return bool as it can't fail)

Internally, that would decompose in the standard way ((see libvterm et.al.)) into an internal rect->rect copy operation, followed by an erase (or two, in the case of a diagonal scroll).

I'm not sure I like the name "scroll" though as it suggests to the end-user that it might apply a scrolling operation to the underlying terminal, whereas it won't do that. Maybe it should be written as "copyrect", taking a source and destination rect. This could then perform intra-RB rectangle copying, in a similar way to "blit" performing inter-RB copy.

    void tickit_renderbuffer_copyrect(TickitRenderBuffer *rb, TickitRect dest, TickitRect src);
    void tickit_renderbuffer_moverect(TickitRenderBuffer *rb, TickitRect dest, TickitRect src);

These are internal copy operations within one RB. If required, a totally generic operation of "blitrect" could be added later that takes two RBs and some specification of the rectangles between them, that might just decompose to copyrect if the source and destination RBs were the same.

Making this efficient requires some internal structural changes, but that's implementation detail.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.