On 08/19/14 12:02, Jean-Sébastien Pédron wrote: > On 19.08.2014 19:46, Nathan Whitehorn wrote: >> On 08/19/14 09:28, Jean-Sébastien Pédron wrote: >>> o vt_vga introduces a new callback, vd_bitblt_text_t, which takes >>> as argument the text buffer, the dirty area, the font and the >>> cursor (position, map, colors). >> Why is this necessary? I'd really prefer to avoid complicating this API. >> One of the great things about writing newcons drivers is that there is >> basically only one function you need to implement. If the current API >> does not provide enough information to do this efficiently, I'd much >> rather change it than add new callbacks. > I don't want to have two callbacks for the same feature either, and I'd > like to transition other drivers to this new one. > > The current bitbltchr callback only knows about one character. In the > case of vt_vga, if this character (or the cursor) isn't aligned on > 8-pixels boundaries, it needs to redraw several "blocks" of pixels. With > this character-centric approach, if a block needs a redraw, it'll be > refreshed for the character on its left side, then refreshed again for > the character on its right side. > > The advantage of giving the callback the whole text/area is that it > allows the driver to manipulate the pixels block by block, instead of > character by character. > > The patch isn't finished yet. Meanwhile, I'll commit the bug fixes I > made (especially the cursor handling in vt_flush()). But eventually, the > plan is to convert all drivers to this new callback, if you find the new > API sensible. > That sounds great. There are only a few (3?) discrete implementations of bitbltchr in the tree right now, so the conversion should be easy. -NathanReceived on Tue Aug 19 2014 - 19:18:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC