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

Display (bitmap overlay)

  • 355 Replies
  • 83379 Views
Re: Display (bitmap overlay)
« Reply #240 on: 06 / May / 2021, 12:50:33 »
Advertisements
@philmoz

One additional thought, as you get this new display arrangement up and running.

Is there any chance you can implement a user accessible ‘guard pixel’ feature in the Lua api?

This will allow scripters to ensure their drawing can be auto refreshed if it disappears, eg as you switch between LCD and EVF, or, as in my use case, where I’m outside ALT mode, but the script is running, and I could be switching between Canon screens.

Re: Display (bitmap overlay)
« Reply #241 on: 06 / May / 2021, 13:13:45 »
@philmoz

A short test of the HDMI out from the M3.

You can see the CHDK offset and the 'odd' flashing.

Cheers

Garry

https://www.dropbox.com/s/ctudp1uvu38n5mg/decodeVideo.MP4?dl=0
« Last Edit: 06 / May / 2021, 15:10:18 by pigeonhill »

*

Offline Ant

  • ****
  • 491
Re: Display (bitmap overlay)
« Reply #242 on: 06 / May / 2021, 17:20:17 »
I compiled this branch(5883) for EOS M3 101a and got a problem:
"ASSERT!! MakeOsdVram.c Line 603"
It happens when I turn on the camera in the Rec mode with HDMI cable connected.
When I turn on the camera in playback mode it's ok.
This is caused by _transfer_src_overlay. It seems that CHDK calls this function at an inappropriate moment.

Also the Viewfinder doesn't work in the CHDK-PTP program:
"chdkptp-r964\lua\gui_live.lua:559: width  > buffer_width"

*

Offline reyalp

  • ******
  • 13450
Re: Display (bitmap overlay)
« Reply #243 on: 06 / May / 2021, 17:55:51 »
I compiled this branch(5883) for EOS M3 101a and got a problem:
"ASSERT!! MakeOsdVram.c Line 603"
It happens when I turn on the camera in the Rec mode with HDMI cable connected.
When I turn on the camera in playback mode it's ok.
This is caused by _transfer_src_overlay. It seems that CHDK calls this function at an inappropriate moment.
Likely similar to https://chdk.setepontos.com/index.php?topic=13993.msg142674#msg142674 possibly avoided by checking draw_is_suspended before redrawing, like elph130 does.

Quote
Also the Viewfinder doesn't work in the CHDK-PTP program:
"chdkptp-r964\lua\gui_live.lua:559: width  > buffer_width"
If CHDK is drawing on a RGB buffer, but live view is using the YUV buffer, those dimensions will need to be identical or (more likely) disentangled.
Don't forget what the H stands for.


*

Offline Ant

  • ****
  • 491
Re: Display (bitmap overlay)
« Reply #244 on: 06 / May / 2021, 18:31:37 »
Likely similar
But on previous builds(r5846) there was no this problem.

SRSA's method using FW_YUV_LAYER_BUF doesn't look beautiful on HDMI.
So I used the gap between two bitmap buffers. In the worst case(HDMI mode, don't know about EVF) it gives me:
0x415C1000-(0x41441000+960*540*2)=536064 Bytes > 480*270*4
Check your addresses...

*

Offline srsa_4c

  • ******
  • 4426
Re: Display (bitmap overlay)
« Reply #245 on: 06 / May / 2021, 18:38:00 »
When using the mzrm_sendmsg debug hook, both XimrExe and XimrExeGain messages need to be handled (same ximr struct is used in both). XimrExeGain is used when the Canon overlay is faded in/out. Ant actually mentioned this a few pages ago. Could be responsible for some of the display glitches reported by pigeonhill.

*

Offline srsa_4c

  • ******
  • 4426
Re: Display (bitmap overlay)
« Reply #246 on: 06 / May / 2021, 18:54:35 »
0x41441000+960*540*2
I have the yuv buffer's opacity buffer there, have you checked that? Nevermind. Not the same buffer.
« Last Edit: 06 / May / 2021, 18:57:19 by srsa_4c »

*

Offline Ant

  • ****
  • 491
Re: Display (bitmap overlay)
« Reply #247 on: 06 / May / 2021, 19:02:36 »
On M3 opacity buffers are 0x41741000 and 0x41801000.

But the problem could be in EVF mode:
0x415C1000 - 0x41441000 = 1024*768*2 - no space for CHDK buffer


*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: Display (bitmap overlay)
« Reply #248 on: 06 / May / 2021, 21:59:58 »
But on previous builds(r5846) there was no this problem.


The change appears to be from replacing the call to vid_bitmap_erase in update_ui with a call to gui_set_need_restore.


Still testing to see if just using vid_bitmap_erase is sufficient.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: Display (bitmap overlay)
« Reply #249 on: 06 / May / 2021, 22:50:30 »
You can see the CHDK offset and the 'odd' flashing.

@pigeonhill

Not sure about the flashing; but the console position is not offset - it's just that the HDMI buffer is taller (270 vs 240) so there is more space below it.

The <ALT> message is always anchored to the bottom of the screen; but the console position is set by the top left corner.

Attached is a new version to test.

The main change is the addition of a new Lua script function screen_needs_refresh() - if this returns true then the CHDK screen has been cleared and you should redraw your display.

After detecting screen_needs_refresh returning true be careful what you call. If anything you call triggers a CHDK UI refresh then this will set screen_refresh_true again and your code will spend a lot of time redrawing - it will likely flicker like crazy.
For example:
- do not call draw.redraw, use draw.overdraw instead. draw.redraw clears the CHDK UI and will trigger a screen_needs_refresh being set again
- if you want to refresh the console call console_redraw(1) to prevent the console from also triggering screen_needs_refresh being set again.

This screen_needs_refresh() function is just an idea I am playing with and it may change - I'm sure reyalp will have a better method to do this  :)

The histogram size should also be correct now.
The EVf size has also been changed to 360x270.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics