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

Display (bitmap overlay)

  • 403 Replies
  • 129153 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
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.

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 reyalp

  • ******
  • 14086
Re: Display (bitmap overlay)
« Reply #401 on: 14 / May / 2022, 01:47:01 »
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.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos
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.

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

  • *
  • 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 »
Magic Lantern / EOS R / 200D


 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal