mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-09-09 18:16:09 +00:00
Paul KilarandClaude Opus 5
bd34414c6d
Clicking a file that holds a picture - EF_DG2, EF_DG7 - showed nothing at all: no image, no hex dump, and no error either. Both panes drew their text into a single Kivy Label, and a Label is one OpenGL texture, capped at commonly 16384px. A monospace line here is 13px, so past roughly 1260 lines the texture fails to be created and the pane draws nothing. A DG2 portrait is 15-25kB, which is 940-1560 dump lines at 16 bytes a row and four times that in a narrow pane, where the dump falls back to 4 bytes a row. The LOG pane holds 4000 lines, so it blanked as well once a dump got talkative. The 64kB cap already in the hex view guarded the wrong bound: it was sized for how long a Label takes to lay out, not for what the GPU will hold. Split both over several Labels. split_blocks() chunks at 512 rows, and the log at 256 because its lines wrap and so cover more rows than they hold. The log reuses its Labels and only assigns the ones whose text changed, so streaming output still re-renders just the tail. The FILES tab now also shows the picture above the dump for the files that carry one, which is what you actually want to see for a DG2. The PNG is already decoded at load time for the data page, so image_for() only hands over what is there. Behaviour change: a file carrying an image shows it above the hex dump, with the dump still underneath. Nothing is truncated that was not before. Testing: 270 passed, 2 skipped (was 265). Checked on screen against a generated sample - EF_DG2 shows the portrait, EF_DG7 the signature, EF_SOD the dump at full height, and the LOG tab renders a full 4000-line buffer as 16 Labels, tallest texture 3328px against the 16384px maximum. black clean. Python only, so no client or firmware build matrix applies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
