Display (bitmap overlay) - page 7 - General Discussion and Assistance - CHDK Forum  

Display (bitmap overlay)

  • 403 Replies
  • 123907 Views
Re: Display (bitmap overlay)
« Reply #60 on: 28 / March / 2017, 12:41:00 »
Advertisements
I must misunderstand something here.  If the primary update task executes every 30ms, that's about 30fps.  We should not be able to see flickering at that rate. Worst case 30ms pass before the chdk stuff is redrawn.  Or is the average/worst case actually much worse, like 80/250ms?

Re: Display (bitmap overlay)
« Reply #61 on: 28 / March / 2017, 12:48:44 »
I must misunderstand something here.  If the primary update task executes every 30ms, that's about 30fps.  We should not be able to see flickering at that rate. Worst case 30ms pass before the chdk stuff is redrawn.  Or is the average/worst case actually much worse, like 80/250ms?
The update task does not redraw the screen each time it runs.  The code I referenced in my previous post can detect some limited situations where a redraw is needed.  But for the most part the display info is only written once and not refreshed.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #62 on: 28 / March / 2017, 13:04:40 »
I must misunderstand something here.  If the primary update task executes every 30ms, that's about 30fps.  We should not be able to see flickering at that rate. Worst case 30ms pass before the chdk stuff is redrawn.  Or is the average/worst case actually much worse, like 80/250ms?
Drawing is done in spytask. It cycles approx. 50 times a second because of this
Code: [Select]
        msleep(20);in its main loop. GUI is refreshed in every fourth cycle:
Code: [Select]
            if (((cnt++) & 3) == 0)
                gui_redraw();

edit:
The guard pixel based forced redraw is only used in a few CHDK GUI modes (don't remember the proper terminology), such as the CHDK menu. It can only detect when the top left pixel of the overlay is erased.

edit2:
And of course, spytask is in core/main.c
« Last Edit: 28 / March / 2017, 13:19:58 by srsa_4c »

*

Offline reyalp

  • ******
  • 14080
Re: Display (bitmap overlay)
« Reply #63 on: 28 / March / 2017, 13:23:39 »
I must misunderstand something here.  If the primary update task executes every 30ms, that's about 30fps.
No. See the main loop in core/main.c

Spytask tries to run at 20 ms intervals (but of course, it might not if the system is busy), and gui_redraw runs once every 4 spytask iterations. So yes, 80 ms.

Quote
We should not be able to see flickering at that rate.
This is not really true. Around 30 FPS is about where animation of similar images appears smooth, but that's not what's happening here.

Isn't that essentially what philmoz's  draw_test_guard() & draw_set_guard() code in core/gui_draw.c tries to do?
That tries to detect when an update is needed, but it doesn't make the update happen sooner than it otherwise would in the 80ms cycle. You could set a flag skip the "every 4th iteration" logic. You could also trigger a redraw with some kind of synchronization object, or directly from whatever task was detecting the need for updates, but spytask does more than drawing, so this might take some work.

Quote
Frankly, I don't care if CHDK sucks down almost 100% of the CPU if it fixes flicker
I don't think simply upping the frame rate would help that much, but you could try making gui_redraw run every iteration and see what happens.

Quote
- 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.
I don't really agree with this: The Canon UI getting laggy is really annoying, and this already happens on G7X when the Canon and CHDK UIs are fighting. Also, I don't think it's safe assume that the Canon firmware will degrade gracefully (i.e. continuous AF just runs a bit slower) if CHDK hogs the CPU.

Making the UI smooth is a worthy goal, but aside from the D6 specific issues, it's a bit OT for this thread. IMO, to make it really look good, we'd have to actually integrate with the Canon drawing system (probably involving the "controller" system, or maybe something with the GPU code on D6), but if there are other changes that offer a significant improvement without negative side effects, I'd certainly consider them.
Don't forget what the H stands for.


Re: Display (bitmap overlay)
« Reply #64 on: 28 / March / 2017, 15:26:01 »
Watching my sx60hs display flicker under conditions of maximum Canon Ui activity, I think I see some periodicity: about 3 flickers than a pause then 3 more every 2-3 seconds, indicating the Canon Ui and chdk differ in frequency by an approximately constant number of hertz. 

*

Offline reyalp

  • ******
  • 14080
Re: Display (bitmap overlay)
« Reply #65 on: 02 / April / 2017, 15:42:04 »
Getting back to srsa_4c's patch: I don't see any reason it shouldn't be checked in. I seems like the right direction and it will be easier to continue development with it in the main source. With the MD update I think the risk of breaking pre digic 6 cameras is low.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #66 on: 02 / April / 2017, 20:15:20 »
Getting back to srsa_4c's patch: I don't see any reason it shouldn't be checked in. I seems like the right direction and it will be easier to continue development with it in the main source. With the MD update I think the risk of breaking pre digic 6 cameras is low.
I think I should have said "check it in if it seems good enough".
Anyway, some new concerns, not on my previous list:
- the draw_hline() rotated OSD fix causes approx. 0.5% drop in character drawing performance on pre-D6 cameras, due to the added check
- decisions based on font size are inconsistent
Examples:
core/gui_draw.c draw_icon_cmds()
modules/gui_osd_edit.c

I checked in the draw_hline() fix regardless, because I have no immediate idea on improving performance.
I would prefer the unrelated OSD rotate fix be checked in separately.

You can proceed with the rest, changed or unchanged.

*

Offline reyalp

  • ******
  • 14080
Re: Display (bitmap overlay)
« Reply #67 on: 02 / April / 2017, 22:28:00 »
You can proceed with the rest, changed or unchanged.
OK, I checked it in as-is in 4780. Thanks again for putting this together.

Quote
- the draw_hline() rotated OSD fix causes approx. 0.5% drop in character drawing performance on pre-D6 cameras, due to the added check
I checked in the draw_hline() fix regardless, because I have no immediate idea on improving performance.
I'm wouldn't worry about a fraction of a % performance difference to fix a bug.

Quote
- decisions based on font size are inconsistent
core/gui_draw.c draw_icon_cmds()
modules/gui_osd_edit.c
I'm not sure I follow. Do you mean using #ifs vs runtime, or something else?
Don't forget what the H stands for.


Re: Display (bitmap overlay)
« Reply #68 on: 02 / April / 2017, 22:32:33 »
So now we need to verify histogram and zebra. Fix histogram default position?

*

Offline reyalp

  • ******
  • 14080
Re: Display (bitmap overlay)
« Reply #69 on: 02 / April / 2017, 23:13:23 »
So now we need to verify histogram and zebra. Fix histogram default position?
It's not bad unless you the R G B mode, but it would be good to match the other cams I guess.

The other display related item left is edge overlay. I know you and ant had code for this. The last one I tried didn't erase properly when updating live (on the initial half press) but otherwise seemed OK.
Don't forget what the H stands for.

 

Related Topics