← index #2692Issue #2572
Related · high · value 2.908
QUERY · ISSUE

RFC modframebuf.c scrolling behaviour

openby peterhinchopened 2016-12-17updated 2024-09-29
enhancement

Currently framebuf_scroll does not clear the region of the display which is exposed by scrolling. While I appreciate that this behaviour is by design, I'd submit that it's seldom what is actually required.

An option would be good, perhaps via a colour arg:

  1. Behave as at present leaving exposed region unchanged.
  2. Fill with a colour.

Any thoughts, or reasons why the current behaviour has been chosen?

CANDIDATE · ISSUE

extmod/modframebuf.c framebuf1_text() does not clear pixels

openby peterhinchopened 2016-10-29updated 2016-11-11

This section of the code looks wrong:

                    if (vline_data & 1) { // only draw if pixel set
                        if (0 <= y && y < self->height) { // clip y
                            uint byte_pos = x0 + self->stride * ((uint)y >> 3);
                            if (col == 0) {
                                // clear pixel
                                self->buf[byte_pos] &= ~(1 << (y & 7));
                            } else {
                                // set pixel
                                self->buf[byte_pos] |= 1 << (y & 7);
                            }
                        }

If the pixel is not set, it should surely clear down the pixel in the framebuf as we don't know its prior contents. Further, if we happen to be drawing with col==0 to a part of the framebuf which is already zero, then nothing will be drawn, because in that circumstance the code never sets a pixel.

I hope I'm right on this observation from reviewing the code: I haven't had the opportunity to try it since my SSD1306 was DOA.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied