Display (bitmap overlay)

philmoz

3450

Re: Display (bitmap overlay)

« Reply #400 on: 12 / May / 2022, 23:40:41 »

Advertisements

Next steps?

All of the existing D6 & D7 cameras with working ports now have XIMR drawing support so what now?

I think it makes sense to promote 1.6 to release status and create a 1.7 dev branch before merging.

There is still a question on what to do with the YUV drawing code.
One option is to remove it and just keep the 8 bit and XIMR versions.
As reyalp pointed out earlier initial porting of other cameras may be easier with the YUV drawing system; but that means keeping three drawing variants.

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)

reyalp

14082

Re: Display (bitmap overlay)

« Reply #401 on: 14 / May / 2022, 01:47:01 »

Quote from: philmoz on 12 / May / 2022, 23:40:41

I think it makes sense to promote 1.6 to release status and create a 1.7 dev branch before merging.

This seems reasonable. I might try to slip a few other things into 1.6.

Quote

There is still a question on what to do with the YUV drawing code.
One option is to remove it and just keep the 8 bit and XIMR versions.
As reyalp pointed out earlier initial porting of other cameras may be easier with the YUV drawing system; but that means keeping three drawing variants.

Yeah, I'm still not sure what the best approach is. I would really like not to have 3 different drawing codebases, but implementing the XIMR method in a brand new port might be ugly. I suppose if someone gets stuck on a port, it would be to hard to switch to the pre XIMR tree. If we keep the D6 YUV code but don't use it, there's a fair chance it will be broken when someone does go to use it.

The other idea I had is an ifdef with some minimal YUV draw capability, just enough to draw text or something, but I'm not sure this is doable or worthwhile.

Logged

Don't forget what the H stands for.

philmoz

3450

Re: Display (bitmap overlay)

« Reply #402 on: 17 / May / 2022, 03:28:01 »

I've updated the XIMR branch to make the RGBA drawing the default for Digic 6 and 7 cameras. I've kept the YUV drawing system.

I also reworked the gui_draw code to hopefully make it more manageable; the changes may not be to everyones liking and I'm open to suggestions to improve it.

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)

kitor

20

Re: Display (bitmap overlay)

« Reply #403 on: 10 / July / 2023, 08:58:00 »

Sorry to bump an old thread.

However I found something on EOS that may interest you.

https://www.magiclantern.fm/forum/index.php?topic=26024.msg244043#msg244043

Quote from: kitor

A few days ago I was able to achieve this. Full double-buffered ML menu with hardware indexed rgb -> RGBA rendering on Zico.

While old method felt "laggy" and was prone to rendering glitches, this is so damn fast. Feels exactly like using 5D3.

This is all thanks to a single Zico function - GrypDsCoreDrawImageToVramForEqualPhase.

Caveats? Of course they are caveats Camera likes to randomly lock up (literally lock, UART output hangs mid-print) on Canon main menu enter.
This happens on R, I wasn't able to trigger it on 80D (D6) and 77D (D7). No other models were tested yet.

Code: [Select]

typedef struct Region{
  uint32_t x;
  uint32_t y;
  uint32_t w;
  uint32_t h;
} Region;

extern uint32_t mzrm_GrypDsCoreDrawImageToVramForEqualPhase
                (struct MARV*, struct Region*,
                    uint32_t target_x, uint32_t target_y,
                    void * buf, uint32_t bits_per_pixel, uint32_t source_w, uint32_t source_h,
                    uint32_t source_cut_x, uint32_t source_cut_y, uint32_t source_cut_w, uint32_t source_cut_h,
                    uint32_t isTransparent);

uint8_t * pIndexedBuffer = some_indexed_rgb_buffer;
mzrm_GrypDsCoreDrawImageToVramForEqualPhase(pRgbaBuffer, NULL, 0, 0, pIndexedBuffer, 8, 960, 270, 0, 0, 960, 270, 1);
pIndexedBuffer+= 960*270;
mzrm_GrypDsCoreDrawImageToVramForEqualPhase(pRgbaBuffer, NULL, 0, 270, pIndexedBuffer, 8, 960, 270, 0, 0, 960, 270, 1);

This code allows hardware-accelerated indexed RGB -> RGBA conversion. I did it in two passes (top and bottom part of the buffer) as I wasn't able to make it process more than 960x500 at once (and target is 960x540). I tried to explore Zico code but found no direct explanation on that.

Anyway, this was tested on 80D, 77D, R (D6,D7,D8) models. Method is unstable on D8 (camera hard locks in some cases, D8 is out of context for CHDK anyway), seems to work fine but slow on D6/7.
If that works for you, then likely you can have single indexed RGB backend for all models, with just a little extra code to wrap it up on D67.

I found that this arg with Region struct pointer is ignored Zico-side, so it can be just nullptr. bits_per_pixel can be either 8 for colour and 1 for black and white image. Other values are ignored. RGBA buffer may need 0x100 alignment, but if you draw directly to Canon buffers they should be already aligned properly.

« Last Edit: 10 / July / 2023, 09:09:35 by kitor »

Logged

Magic Lantern / EOS R / 200D