Quote:
Originally Posted by NiLuJe
@Mavireck: True, I definitely get that for more complex setups, it can get hairier  .
(And, no matter the state of the code, seeing what people do with it is a great way for me to tweak stuff, hence my pesky questions ;p).
That said, you do have access to a dump's width/height & position, so it should be usable for clipping detection, too. (Unless I'm missing something obvious, in which case, do remind me ).
Looking at the code, I can somewhat understand that once you start chopping rectangles up in little bits, being able to crop stuff starts coming in handy .
That was indeed left to the user (and it can get a bit tricky when you want to do it in-place with only a memory buffer on hand), so I added support for that to the dump/restore API, since it was already messing with pixel formats and memory buffers internally, and the "metadata" needed to do it right was mostly already all there .
EDIT: ... Which I've just fixed ;p. Not quite sure if it's more usable this way than via an FBInkRect to handle the crop settings... |
You are extremely reactive for improvements!
I will think about it, to see if I can improve the code clarity or performance using cropped dumps. But as far as simplicity and clarity are concerned, I think print_raw_data is more than enough for my use