Quote from: theBilalFakhouri on October 01, 2022, 04:52:55 PM
This part of code:Code Select/* be gentle with the CPU, save it for recording (especially if the buffer is almost full) */
msleep(
(need_for_speed)
? ((queued_frames > valid_slot_count / 2) ? 1000 : 500)
: 50
);
Controls when it's okay to refresh Framing preview depending on RAW recording state, this part of code add delays while recording for Framing preview to slow down refresh rate.
If you removed this part of code you will have semi real-time preview in B&W during RAW recording, of course this will make CPU usage 100% all time and there is high chance you will have corrupted frames.
But we can probably fine-tune the delay (reduce it), play with 1000 and 500 values (decrease them).
1000 and 500 are in milliseconds.
I am playing with this now. I think the only way to test for stability is to record in a resolution that is higher than continuous because the slot error happens when the buffer is full, any thoughts?
also:
I noticed Danne modified these values in Raw.c:
Code Select
/* scale useful range (black...white) to 0...1023 or less */
+ /* changing from 1024 to 700 for speed reasons */
int black = raw_info.black_level;
int white = raw_info.white_level;
int div = 0;
- while (((white-black) >> div) >= 1024)
+ while (((white-black) >> div) >= 700)
{
div++;
}
- uint8_t gamma[1024];
+ uint8_t gamma[700];
- for (int i = 0; i < 1024; i++)
+ for (int i = 0; i < 700; i++)
Does this reduce CPU overhead?