~mstoeckl

https://mstoeckl.com

Trackers

~mstoeckl/shaderbg

Last active 8 months ago

#85 Segmentation fault 4 months ago

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 = 1339340 by 1338500, and any image of that size requires much more memory to store than is available; thus creating common_image fails, and grim crashes later on.

#85 Segmentation fault 4 months ago

Comment by ~mstoeckl on ~emersion/grim

Sorry, I should have been more precise: could you please post the WAYLAND_DEBUG=1 grim logs 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, like zxdg_output_manager_v1@6.destroy(), that only run after grim has saved an image.)

Alternatively, inside gdb, run bt full to get a stack trace that (assuming a debug build) prints the state of all variables on the stack.

#85 Segmentation fault 4 months ago

Comment by ~mstoeckl on ~emersion/grim

The following line of the backtrace suggests that the pixman_image_t * common_image is 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, run WAYLAND_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,

#83 Investigate saving images to AVIF format 5 months ago

enhancement added by ~mstoeckl on ~emersion/grim

#83 Investigate saving images to AVIF format 5 months ago

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 avif at 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.c using 444 YUV subsampling instead of write_jpg.c's 420 subsampling.

#1 Allow running shadertoy shaders without modification 8 months ago

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.

#78 Investigate saving images to JPEG XL format 10 months ago

enhancement added by ~mstoeckl on ~emersion/grim

#78 Investigate saving images to JPEG XL format 10 months ago

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 jxl under 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