Display (bitmap overlay) - page 19 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 14 15 16 17 18 [19] 20 21 22 23 24 25   Go Down

Display (bitmap overlay)

  • 242 Replies
  • 62699 Views
*

Online pigeonhill

  • *****
  • 647
Re: Display (bitmap overlay)
« Reply #180 on: 22 / April / 2021, 01:45:05 »
Advertisements
Please forgive me if this post doesn’t link to the topic.

My feedback is that on my M3, the CHDK drawing is always skewed left relative to the image, when I use HDMI out.
Logged
*

Offline srsa_4c

  • ******
  • 4393
Re: Display (bitmap overlay)
« Reply #181 on: 22 / April / 2021, 12:06:23 »
Quote from: philmoz on 21 / April / 2021, 19:18:45
Additional RGBA layers are rendered twice when using HDMI. They are rendered once at the RGBA frame size and again at the YUV frame size on the screen. The attached image shows this - only two blue boxes were drawn into the RGBA layer.
I just tried, happens on m10 as well.
When I copied the second layer (which uses the first RGBA buffer and is used for most of overlay) ximr struct to a later layer and zeroed out the second layer struct, I seemingly got identical result to normal, no double draw.
I suspect the key is somewhere in the ximr struct.
Quote
The RGBA layers are not full screen when using HDMI, they are smaller and centered (affects Canon UI as well).
The ximr struct does have data that looks like border size in that case.

Could you make dumps of the whole struct on your g5x? It has 3 different resolution output devices, seeing one dump for each could be helpful. I only have lcd and hdmi.
Logged
*

Offline philmoz

  • *****
  • 3275
    • Photos
Re: Display (bitmap overlay)
« Reply #182 on: 22 / April / 2021, 20:40:10 »
Attached zip file has ximr context dumps from LCD, EVF and HDMI.

I am copying layer[1] (second layer) from offset 0x48+0x3c in the ximr context data - in HDMI the first layer looks like YUV format.

I can see the centering offsets in the layer struct just before the 'MARV' marker - changing these I can make the RGBA layer full screen; but I still get the double rendering (even if I zero out the second layer).

Edit: I also tried just replacing the RGBA buffer pointer in the 2nd layer and not modifying anything else - I still get the double rendering  ???


On a side note - one plus in all this is that patching dry_memcpy and checking if the call is from the function that updates the display gives a very reliable way to detect when the CHDK UI needs to be refreshed. I've tried this on the G5X and G7X2 to replace the current guard pixel logic and it gives a much better CHDK UI with much less flickering.

Phil.
« Last Edit: 22 / April / 2021, 20:47:19 by philmoz »
Logged
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 srsa_4c

  • ******
  • 4393
Re: Display (bitmap overlay)
« Reply #183 on: 23 / April / 2021, 17:12:24 »
Quote from: philmoz on 22 / April / 2021, 20:40:10
Attached zip file has ximr context dumps from LCD, EVF and HDMI.
Thanks. From a quick look, the ximr structure seems to match the m10 struct.
Quote
Edit: I also tried just replacing the RGBA buffer pointer in the 2nd layer and not modifying anything else - I still get the double rendering
I had a thought that maybe the zico side needs to know the buffers in advance, so I added an offset (+256) to the 2nd layer's rgba buffer address. Aside from the shifted view, no artifacts are visible on hdmi output (no double drawing).

@kitor: Can you check whether your cameras have such drawing issues on HDMI?
Logged
*

Offline kitor

  • *
  • 18
Re: Display (bitmap overlay)
« Reply #184 on: 23 / April / 2021, 17:45:52 »
Double rendering - no. Magic Lantern menus worked fine on my own layer on HDMI output of EOS R.
Maybe your buffers overlap or something?

Part of layer definition structure in XimrContext contains offsets that are cut off from full buffer (not rendered) and layer offset (move "0,0" somewhere else on screen). See XimrSetLayerDimensions:

src_x, src_y, src_w, src_h is region from buffer that will be rendered. Everything outside this region is just not visible (not rendered / transparent). This will "crop" potential junk that you don't want to be visible.

dst_x, dst_y is offset in output buffer where 0,0 from input layer will be rendered. With that you can move output horizontally and vertically.

Additionally, somewhere in XimrContext structure there is scaling ratio (or really two ratios - horizontal and vertical) set. Those apply to all layers and are used to up/downscale from layers to output buffer. This is set once per XimrContext, so it applies to all layers at once - thus as long as you alter Canon generated XimrContext this should be fine.

All those params change for each output type. They are different for LCD, HDMI, EVF (or in general per output YUV resolution). So when switched to HDMI, you would need to update both crop region and offsets to probably something like (0,0, buf_w, buf_h),(0,0) to both properly start buffer from 0,0 and tell Zico to render whole buffer content.

For horizontal shift there maybe an issue with buffer memory alignment - i touched that topic in my writeup, I had to memory-align buffers on Digic 7 to 256 blocks - see my PoC from chapter 1.2
But if this would be the issue, you would get a random shift on every boot / buffer allocation unless your method of malloc returns the same address every time ;)
« Last Edit: 23 / April / 2021, 17:53:55 by kitor »
Logged
Magic Lantern / EOS R / 200D
*

Offline philmoz

  • *****
  • 3275
    • Photos
Re: Display (bitmap overlay)
« Reply #185 on: 23 / April / 2021, 18:39:48 »
Quote from: srsa_4c on 23 / April / 2021, 17:12:24
I had a thought that maybe the zico side needs to know the buffers in advance, so I added an offset (+256) to the 2nd layer's rgba buffer address. Aside from the shifted view, no artifacts are visible on hdmi output (no double drawing).

Try shifting it by a larger negative amount.
In the attached image I have copied layer 2 and just adjusted the RGBA buffer address lower in memory by 40 rows.

I have no explanation for this - it is just weird.

Edit: This also happens if I just change the RGBA buffer address in layer 2 by the same amount without duplicating the layer (2nd screenshot).

Phil.



« Last Edit: 23 / April / 2021, 18:47:37 by philmoz »
Logged
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 kitor

  • *
  • 18
Re: Display (bitmap overlay)
« Reply #186 on: 24 / April / 2021, 07:27:42 »
Quote
Try shifting it by a larger negative amount.
I'm 99% sure this is your problem. I never tried to shift layer by "negative amount", only positive. And srsa confirms no issues on that.

Can you dump XimrContext struct for me while this weird issue is visible?
Logged
Magic Lantern / EOS R / 200D
*

Offline philmoz

  • *****
  • 3275
    • Photos
Re: Display (bitmap overlay)
« Reply #187 on: 24 / April / 2021, 07:52:05 »
Quote from: kitor on 24 / April / 2021, 07:27:42
Quote
Try shifting it by a larger negative amount.
I'm 99% sure this is your problem. I never tried to shift layer by "negative amount", only positive. And srsa confirms no issues on that.

Can you dump XimrContext struct for me while this weird issue is visible?

Attached is a zip file with the ximr context dump from the second screen shot in my earlier post.
The only change made to the context is to shift the RGBA buffer address in the second layer as I described. Everything else is unchanged.

In this dump the buffer address is 0x42584800, the normal address is 0x425aa000.

Edit: This is from the G7X2 as were the earlier screen shots. The G5X behaves the same.

Phil.
« Last Edit: 24 / April / 2021, 07:55:35 by philmoz »
Logged
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 kitor

  • *
  • 18
Re: Display (bitmap overlay)
« Reply #188 on: 24 / April / 2021, 13:03:17 »
Hi,
According to your dump:
OutputChunk:
Code: [Select]
Layer config:
- width: 960
- height: 540
VRAM struct:
- width: 1024
- height: 768
- pBitmap @ 0x7FD00000
- pOpacity @ 0x7FB80000
- flags: 0x1040280 (UYVY + Alpha)
Layer 0 (Canon):
Code: [Select]
Layer config:
- color_type: 1 (UYVY + Alpha ?!?!)
- src_x: 0
- src_y: 0
- src_w: 960
- src_h: 540
- dst_x: 0
- dst_y: 0
VRAM struct:
- width: 1024
- height: 768
- pBitmap @ 0x4196A000
- pOpacity @ 0x41AEA000
- flags: 0x1040280 (UYVY + Alpha ?!?!)
Layer 1 (yours):
Code: [Select]
Layer config:
- color_type: 5 (RGBA)
- src_x: 0
- src_y: 0
- src_w: 720
- src_h: 480
- dst_x: 120
- dst_y: 30
VRAM struct:
- width: 960
- height: 540
- pBitmap @ 0x42584800
- pOpacity @ 0x0
- flags: 0x5040100 (RGBA)
Please note, I might have swapped src_x/y with dst_x/y. Digic 8 uses slightly different struct in terms of both fields order and data types.

This both answers and raises some questions.

First, looks like Canon switches to YUV GUI rendering ?! It uses 1024x768 YUV buffer and renders 960x540 starting from 0,0.
Since output is also 960x540 - I believe scaling factor is 1:1 (idk where it is located in XimrContext).

With that said, your layer is 960x540 RGBA but you told it to render 720x480 starting from 120,30. This is probably source of most problems.
Change layer config to 960x540 from 0,0 - like Canon layer does.
Code: [Select]
Layer config:
- color_type: 5 (RGBA)
- src_x: 0
- src_y: 0
- src_w: 960
- src_h: 540
- dst_x: 0
- dst_y: 0

I believe this will solve your layer offset problems.

I attached partial grammar for Hexinator. If you load your dump + this grammar, you can see what different fields mean. This is specific for dump provided, as XimrContext may differ on other cameras.

« Last Edit: 24 / April / 2021, 13:16:17 by kitor »
Logged
Magic Lantern / EOS R / 200D
*

Offline philmoz

  • *****
  • 3275
    • Photos
Re: Display (bitmap overlay)
« Reply #189 on: 24 / April / 2021, 17:19:40 »
Quote from: kitor on 24 / April / 2021, 13:03:17
With that said, your layer is 960x540 RGBA but you told it to render 720x480 starting from 120,30. This is probably source of most problems.
Change layer config to 960x540 from 0,0 - like Canon layer does.


Thanks for looking; but in this dump I have NOT added any new layers to the display. Both layers are Canon layer with Canon values for all properties.


The only change I made was to adjust the Canon RGBA buffer address to demonstrate that the weird rendering issue also happens unless the buffer addresses are exactly what the Canon UI uses. You can see the rendering error at the top of the screen shot where content that should have been off the bottom of the screen is being shown.


Phil.
Logged
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)
Pages: 1 ... 14 15 16 17 18 [19] 20 21 22 23 24 25   Go Up
« previous next »
 

Related Topics