scripts: dbgbmap[d3].py: Prioritize rows at low resolution

This prevents some pretty unintuitive behavior with dbgbmap.py -H2 (the
default) in the terminal.

Consider before:

  bd 4096x256, 7.8% mdir, 0.4% btree, 0.0% data
  mm--------b-----mm--mm--mm--mmmmmmm--mm--mmmm-----------------------

Vs after:

  bd 4096x256, 7.8% mdir, 0.4% btree, 0.0% data
  m-----------------------------------b-mmmmmmmm----------------------

Compared to the original bmap (-H5):

  bd 4096x256, 7.8% mdir, 0.4% btree, 0.0% data
  mm------------------------------------------------------------------
  --------------------------------------------------------------------
  ----------b-----mm--mm--mm--mmmmmmm--mm--mmmm-----------------------
  --------------------------------------------------------------------

What's happening is dbgbmap.py is prioritizing aspect ratio over pixel
boundaries, so it's happy drawing a 4-row bmap to a 1-row Canvas. But of
course we can't see subpixels, so the result is quite confusing.

Prioritizing rows while tiling avoids this.
This commit is contained in:
Christopher Haster
2025-04-28 21:48:10 -05:00
parent 1f4d7b3b7e
commit dc2d58d28e
2 changed files with 8 additions and 6 deletions

View File

@@ -4717,18 +4717,19 @@ def main_(ring, disk, mroots=None, *,
block_cols_ = block_cols
block_rows_ = mt.ceil(len(bmap) / block_cols)
else:
# prioritize rows at low resolution
block_rows_ = min(len(bmap), max(canvas.height, 1)) # was len(bmap)
block_cols_ = mt.ceil(len(bmap) / block_rows_) # was 1
# divide by 2 until we hit our target ratio, this works
# well for things that are often powers-of-two
block_cols_ = 1
block_rows_ = len(bmap)
while (abs(((canvas.width/(block_cols_*2))
/ max(canvas.height/mt.ceil(block_rows_/2), 1))
- block_ratio)
< abs(((canvas.width/block_cols_)
/ max(canvas.height/block_rows_, 1)))
- block_ratio):
block_cols_ *= 2
block_rows_ = mt.ceil(block_rows_ / 2)
block_cols_ *= 2
block_width_ = canvas.width / block_cols_
block_height_ = canvas.height / block_rows_