Display (bitmap overlay) - page 6 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 18   Go Down

Display (bitmap overlay)

  • 177 Replies
  • 60739 Views
*

Offline waterwingz

  • ******
  • 12066
    • Waterwingz
Re: Display (bitmap overlay)
« Reply #50 on: 26 / March / 2017, 21:40:28 »
Advertisements
Quote from: srsa_4c on 26 / March / 2017, 21:08:45
Thanks for the comments.
Quote from: waterwingz on 25 / March / 2017, 16:53:47
Also, I wasn't able to get the d6_display_lores_on_sx280_v1.diff version to work well - looked like buffer sizes were wrong - so I gave up on that one.
I agree that setting up the required display dimensions for the lo-res "rework" is a bit frustrating - the sx280 parts of that patch were meant to give hints on what to do.
Yes - thanks for the hints. We both know the value of those when exploring new territory.  I gave up on spending any time at all on the low-res version once you posted the newer hires versions.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Online reyalp

  • ******
  • 13058
Re: Display (bitmap overlay)
« Reply #51 on: 26 / March / 2017, 22:14:02 »
Quote from: srsa_4c on 26 / March / 2017, 21:08:45
Quote
An alternate approach would be to have a CHDK variable that is only updated at defined points: e.g. before every gui redraw, and/or every kbd_task iteration.
I actually tried something similar to this earlier, on the sx280.
Understood. I'm fine with the current code being added, it's just something I worry about biting us later.
Quote

That happened already - some games look now quite broken due to unexpected font size.
I think this is a different issue. It would be good to fix the games, but I'm not to worried about them.

What I meant was modules for a given instruction set are currently identical, no matter what camera they were built for. Having a hard rule of "no ifdefs in module code" made it easier to recognize mistakes that would break this. Again, I'm not asking for any change right now, just worrying out loud about about how to keep it maintainable ;)

Quote
Quote
Using THUMB_FW to represent both the instruction set and display architecture also seems likely to bite us in the future. I have ideas about this, but it's probably a topic for another post.
I was using a separate #define for yuv overlay before the D6 support was integrated in trunk. I chose to remove it at one point (the sx280 was the only D6 port at that time).
Yeah, without a solution to the module issue (how we define modules for a specific display type, rather than instruction set), it's probably not worth it.

Quote
Quote
jog dial control in the OSD editor is added, should be documented.
I only put that in because I wanted to use something that could replace the missing zoom buttons on my M10. Could probably stay because it can be operated faster than the zoom/halfshoot buttons.
Makes sense, I have no objection to it being added.
Logged
Don't forget what the H stands for.
*

Offline 62ndidiot

  • *****
  • 591
Re: Display (bitmap overlay)
« Reply #52 on: 26 / March / 2017, 22:16:33 »
I somehow doubt low res on a hires display is much faster.  Still got the same number of pixels to manage. Hi res is the right choice, it looks nicer.
I'm very happy with the progress everyone has made and I'm looking forward to when we can solve the flickering and correct bitmap buffer "timing" issues.  Recall we do have a directly accessible memory pointer to the current buffer.
Logged
*

Offline waterwingz

  • ******
  • 12066
    • Waterwingz
Re: Display (bitmap overlay)
« Reply #53 on: 26 / March / 2017, 22:45:25 »
Quote from: 62ndidiot on 26 / March / 2017, 22:16:33
I'm looking forward to when we can solve the flickering
Well, this has been an issue as long as there has been CHDK. I think it's worse now as recent processors update the display buffers more often. 

But the fact that we have not been able to find calls that let us add stuff to the display buffer such that it does not get erased on refresh is a big limitation. For the most part, we have been bypassing the Canon code and writing directly to the display buffers.  And getting erased after each Canon update to the display.

FWIW, there is of course an option to simply write to the display buffer a lot more often.  But that option has been "shot down in flames" in the past as taking too much CPU time.  But IIRC, there has never been a measurement of how much it takes,  or how much is "too much". It's been more an intellectual good code practice argument IMHO.

At some point, I've intended to go back through a couple of my ports and see what vid_bitmap_refresh() , vid_turn_off_updates() , and vid_turn_on_updates() really do if they are nulsub'd out.


« Last Edit: 26 / March / 2017, 22:47:20 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Online reyalp

  • ******
  • 13058
Re: Display (bitmap overlay)
« Reply #54 on: 27 / March / 2017, 00:54:47 »
One bit of display related code I'd forgotten about is autoiso.c live_histogram_read_y, used by custom auto ISO and lua get_live_histo

I checked in code for this in r4777, it shouldn't interact with srsa_4c's patch at all.

I tested get_live_histo to verify that it returns expected results on new and old cameras.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4384
Re: Display (bitmap overlay)
« Reply #55 on: 27 / March / 2017, 21:30:23 »
Quote from: 62ndidiot on 26 / March / 2017, 22:16:33
I somehow doubt low res on a hires display is much faster.
The aim of the lo-res patch was to show an alternative that does not screw up the existing drawing architecture. It has a satisfactory drawing speed. But, as I mentioned, I don't like it because of the resulting pixelated look and short text lines.
Quote from: waterwingz on 26 / March / 2017, 22:45:25
But IIRC, there has never been a measurement of how much it takes,  or how much is "too much".
You can have an idea by using the benchmark (text output, especially "FPS").
Logged
*

Offline waterwingz

  • ******
  • 12066
    • Waterwingz
Re: Display (bitmap overlay)
« Reply #56 on: 27 / March / 2017, 21:38:46 »
Quote from: srsa_4c on 27 / March / 2017, 21:30:23
Quote from: waterwingz on 26 / March / 2017, 22:45:25
But IIRC, there has never been a measurement of how much it takes,  or how much is "too much".
You can have an idea by using the benchmark (text output, especially "FPS").
I could do that. But I gave up.

Frankly, I don't care if CHDK sucks down almost 100% of the CPU if it fixes flicker - other than when the shutter key is pressed or a script is running.  Both easily detected and dealt with. If continuous AF runs slow as a result, so be it.

But I don't expect to win that argument.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline 62ndidiot

  • *****
  • 591
Re: Display (bitmap overlay)
« Reply #57 on: 28 / March / 2017, 01:38:42 »
Would it be possible to run a watchdog task that cycles more frequently than 30 msec?  A very simple task to monitor changes in the active buffer address say every 10 msec and trigger an update from chdk.
Logged
*

Online reyalp

  • ******
  • 13058
Re: Display (bitmap overlay)
« Reply #58 on: 28 / March / 2017, 01:56:16 »
Quote from: 62ndidiot on 28 / March / 2017, 01:38:42
Would it be possible to run a watchdog task that cycles more frequently than 30 msec?  A very simple task to monitor changes in the active buffer address say every 10 msec and trigger an update from chdk.
Sure, physw should theoretically run every 10ms (but might not in some case), or you could create your own task just for this purpose. How "trigger an update" would actually be implemented would need some thought though.

The digic 6 code has more problems than the usual flickering though.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12066
    • Waterwingz
Re: Display (bitmap overlay)
« Reply #59 on: 28 / March / 2017, 03:33:54 »
Quote from: reyalp on 28 / March / 2017, 01:56:16
How "trigger an update" would actually be implemented would need some thought though.
Isn't that essentially what philmoz's  draw_test_guard() & draw_set_guard() code in core/gui_draw.c tries to do?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 2 3 4 5 [6] 7 8 9 10 11 ... 18   Go Up
« previous next »
 

Related Topics