Comment by ~mstoeckl on ~emersion/grim
zxdg_output_v1@3.logical_position(-1337420, -1337420)
This explains the crash. If I understand the code correctly, grim tries to render onto an image which contains both HDMI-A-1 and eDP-1 at the logical positions specified. Since the compositor claims that HDMI-A-1 is very far to the the left, and very far up, the smallest rectangle containing the two has size
1337420+1920 = 1339340by1338500, and any image of that size requires much more memory to store than is available; thus creatingcommon_imagefails, and grim crashes later on.
Comment by ~mstoeckl on ~emersion/grim
Sorry, I should have been more precise: could you please post the
WAYLAND_DEBUG=1 grimlogs from an unsuccessful run, where grim segfaults? {I am assuming grim did not crash here, since the last lines of the log shows cleanup requests, likezxdg_output_manager_v1@6.destroy(), that only run after grim has saved an image.)Alternatively, inside
gdb, runbt fullto get a stack trace that (assuming a debug build) prints the state of all variables on the stack.
Comment by ~mstoeckl on ~emersion/grim
The following line of the backtrace suggests that the
pixman_image_t * common_imageis being set to NULL at render.c#L134. This might be caused by grim receiving incorrect parameters about the outputs from hyprland. Could you please report the Wayland debug log output? (i.e, runWAYLAND_DEBUG=1 grim, and provide the logs that are printed.)
pixman_image_composite32 (op=PIXMAN_OP_SRC, src=0x555555569780, mask=0x0, dest=0x0, src_x=0, src_y=0, mask_x=0,
enhancement added by ~mstoeckl on ~emersion/grim
Ticket created by ~mstoeckl on ~emersion/grim
AVIF can be more space efficient than JPEG at equivalent perceived quality levels. It also supports 10-bit per channel images.
I have a prototype branch implementing this format called
avifat https://git.sr.ht/~mstoeckl/grim/ . Unfortunately, in order to attain a significant space advantage over JPEG, one must use lower speed levels -- which are fairly slow. (On one test screenshot, speed 6 required ~2 CPU seconds, while speed 0 required ~50 seconds.)It may be worth adding AVIF support, despite the slowness, if grim can be set up to write 10-bit screenshots; here JPEG is limited to 8-bit depth and PNG, being lossless, makes much larger files.
The AVIF branch currently preserves text much more accurately than JPEG, but this may be a consequence of
write_avif.cusing 444 YUV subsampling instead ofwrite_jpg.c's 420 subsampling.
Ticket created by ~mstoeckl on ~mstoeckl/shaderbg
This requires introducing a set of new uniform. For full support, some way to load textures will be needed.
enhancement added by ~mstoeckl on ~emersion/grim
Ticket created by ~mstoeckl on ~emersion/grim
This format a) is more space efficient than JPEG at equivalent quality levels, and generally more efficient than PNG when lossless b) will be able to support >8 bits per channel, which would be useful once compositors support HDR and people want better but still lossy screenshots of media.
I slightly prefer this format over the other JPEG replacement candidates (WEBP and AVIF), since those have 10bpp and 12bpp limits; acceptable to be displayed again, but not as good if one wants to, say, do post processing on a (linear color space, 16f pixel) screenshot from a video game. AVIF also has seams at 8k tiles.
I have a prototype branch adding JXL support called
jxlunder https://git.sr.ht/~mstoeckl/grim/ . However, I do not think it is will be worth merging in the near future, because:
- Saving JXL images is noticeably slow, at the moment
- It is not clear what the best command line interface is; should grim save lossless or lossy by default? (The format also has two main encoding modes, Modular and VarDCT, which approximately handle UIs and photos well, respectively. Screenshots may include either category.)
- Not many image viewers have support for the format yet, nor do any web browsers in standard configuration
Some of the API used in the branch will be deprecated by the next libjxl release