Display (bitmap overlay)

philmoz

3450

Re: Display (bitmap overlay)

« Reply #220 on: 04 / May / 2021, 07:30:50 »

Advertisements

Quote from: Ant on 04 / May / 2021, 04:55:14

Quote from: philmoz on 04 / May / 2021, 04:15:55
so no need to parse MZRM stuff.

By parsing, I meant checking the message type number(the 1st word) and taking the address of the XIMR context (the 4th word). This can be done using assembler.
XIMR context in XimrExeGain message also can be modified.

How do you clear the CHDK layer when you enter canon menu?

P.S. Original canon buffers are alligned to 0x1000.

Buffer is cleared using _bzero firmware function (previously used _memset32).
On the G7X2 and G5X the buffers are aligned to 0x100 byte boundary.

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)

Ant

509

Re: Display (bitmap overlay)

« Reply #221 on: 04 / May / 2021, 08:01:41 »

Quote from: philmoz on 04 / May / 2021, 07:30:50

Buffer is cleared using _bzero firmware function (previously used _memset32).

I'm trying to understand not how, but why it is cleaned, when we enter the Canon menu. Previously, the bitmap buffer was cleared when Canon drew its menu.

Logged

Ant

509

Re: Display (bitmap overlay)

« Reply #222 on: 04 / May / 2021, 10:37:41 »

Quote from: reyalp on 03 / May / 2021, 15:25:33

that using exmem can impact the maximum jpeg quality, as well as the conflicts with video buffers.

I got this problem during video playback when I allocated 16MB buffer in ExMem for my logs.
But there is a space between two bitmap buffers on EOS M3 that looks unused...

Logged

philmoz

3450

Re: Display (bitmap overlay)

« Reply #223 on: 04 / May / 2021, 18:17:43 »

Quote from: Ant on 04 / May / 2021, 08:01:41

Quote from: philmoz on 04 / May / 2021, 07:30:50
Buffer is cleared using _bzero firmware function (previously used _memset32).

I'm trying to understand not how, but why it is cleaned, when we enter the Canon menu. Previously, the bitmap buffer was cleared when Canon drew its menu.

Sorry, misunderstood the question.

Attached is an updated patch - in the lib.c update_ui() function for either G5X or G7X2 I have added logic to call gui_set_need_restore() if the camera is switched to play mode or the Canon menu is opened. This will erase the CHDK RGBA layer via the vid_bitmap_erase() function.

This also includes the change to use the debug logging function override instead of dry_memcpy.

EDIT: patch updated. I moved the above logic to the gui_redraw() function in gui.c.

Phil.

rgba_draw_v3.patch (85.93 kB - downloaded 10 times.)

« Last Edit: 04 / May / 2021, 19:08:24 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)

pigeonhill

1164

Re: Display (bitmap overlay)

« Reply #224 on: 05 / May / 2021, 00:46:01 »

@philmoz

Phil if you have the time, and believe it would help your developments, I would love to continue to test things on my M3.

Does your previous guidance still apply regarding scaling things down by 2?

« Last Edit: 05 / May / 2021, 01:06:29 by pigeonhill »

Logged

philmoz

3450

Re: Display (bitmap overlay)

« Reply #225 on: 05 / May / 2021, 02:13:16 »

Quote from: pigeonhill on 05 / May / 2021, 00:46:01

@philmoz

Phil if you have the time, and believe it would help your developments, I would love to continue to test things on my M3.

Does your previous guidance still apply regarding scaling things down by 2?

@pigeonhill - working on a few issues with it at the moment.

I will be busy with other things for a week or so, not sure when I will be able to do another test version.

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)

pigeonhill

1164

Re: Display (bitmap overlay)

« Reply #226 on: 05 / May / 2021, 02:20:00 »

@philmoz

Fully understood.

I’ll wait for you to push test builds my way, when you are ready.

Cheers

Garry

Logged

philmoz

3450

Re: Display (bitmap overlay)

« Reply #227 on: 05 / May / 2021, 02:37:23 »

Using a dedicated RGBA buffer for the CHDK UI definitely make the UI rock solid and avoids massive flickering regardless of what the Canon UI is doing.

One thing that will probably require discussion is what size to make the RGBA buffer?

I'm currently testing this with a quarter size buffer (36x240) and 2x scaling; but I'm sure there are arguments for going with a full size buffer (720x480) and no scaling.

Half size RGBA (360x480)
Pros:
- Requires less memory for buffer (.5MB vs 2MB)
- Drawing code is simpler and faster (and smaller)
- More compatible with scripts and existing logic that was built for this size screen
Cons:
- Does not take advantage of the higher resolution available
- Will require changes to the way the font size values are handled to ensure modules are compatible between YUV and RGBA drawing for Digic 6 & 7
- Changing from YUV to RGBA drawing version requires user reset their CHDK UI config settings on the camera (screen positions are wrong).

I'm sure there are other things I have not considered and would be interested in what others think.

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)

pigeonhill

1164

Re: Display (bitmap overlay)

« Reply #228 on: 05 / May / 2021, 02:54:53 »

@philmoz

When I tested the M3 build version you sent me, I started thinking about this, ie looking ahead to converting my scripts to the ‘new’ display space, ie if it had to be halved.

One thought I had was that we standardise the CHDK drawing area, eg let’s say it will always be 720/480, irrespective of the camera.

This camera independent space then gets scaled in the CHDK backend, on a camera specific basis, if required, and according to the RGBA buffer that is being used.

The main advantages of this approach are that older scripts should run without change and the Lua drawing API could be developed/evolved knowing that drawing space is always 720/480.

Scaling to, say, the EVF will/may introduce differential x/y stretching, but I can’t see this being an issue.

The prize here is to eliminate flickering, standardising/fixing user CHDK drawing space will allow the backend gurus, like you, to press ahead with developments, with the front end scripter, like me, carrying on developing their ideas, with both protected from each other and in sync.

Just my humble initial thoughts.

Cheers

Garry

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #229 on: 05 / May / 2021, 17:42:46 »

Quote from: srsa_4c on 03 / May / 2021, 12:36:51

I would consider using the area where the firmware's yuv layer is drawn. By hooking the ximrexe call that creates it, we could reconfigure the yuv layer to be half height or width (and later double its height (or width) when it is used as input layer). The remaining space in that area is more than enough for a 720x240 RGBA buffer for CHDK - we wouldn't have to allocate any memory.

I implemented this on my m10, using Phil's v1 patch. I went for 720x240, but will probably revert to 1:1 aspect because there is not enough space (in that area) for a full-screen 960x270 rgba buffer.
Note the numer and denom (numerator, denominator) members of ximr_context: these control the magnification of the output.

Code: [Select]

Index: platform/m10/lib.c
===================================================================
--- platform/m10/lib.c	(revision 5875)
+++ platform/m10/lib.c	(working copy)
@@ -204,6 +204,7 @@
 }
 
 
+extern int displaytype;
 #ifdef CAM_SUPPORT_BITMAP_RES_CHANGE
 /*
  * needed because bitmap buffer resolutions change when an external display is used
@@ -211,7 +212,6 @@
  */
 void update_screen_dimensions() {
     // see sub_fc177316 in 110d for the values
-    extern int displaytype;
     static int old_displaytype = -1;
 
     if (old_displaytype == displaytype) {
@@ -278,3 +278,167 @@
     extern char jpeg_count_str[];
     return jpeg_count_str;
 }
+
+// ximr stuff below
+
+// Ximr layer
+typedef struct {
+    unsigned char   unk1[7];
+    unsigned char   scale;
+    unsigned int    unk2;
+    unsigned short  color_type;
+    unsigned short  visibility;
+    unsigned short  unk3;
+    unsigned short  src_y;
+    unsigned short  src_x;
+    unsigned short  src_h;
+    unsigned short  src_w;
+    unsigned short  dst_y;
+    unsigned short  dst_x;
+    unsigned short  enabled;
+    unsigned int    marv_sig;
+    unsigned int    bitmap;
+    unsigned int    opacity;
+    unsigned int    color;
+    unsigned int    width;
+    unsigned int    height;
+    unsigned int    unk4;
+} ximr_layer;
+
+// Ximr context
+typedef struct {
+    unsigned short  unk1;
+    unsigned short  width1;
+    unsigned short  height1;
+    unsigned short  unk5;
+    unsigned int    unk6[9];
+    unsigned int    output_buf;
+    unsigned int    output_opacitybuf;
+    unsigned int    output_color;
+    int             buffer_width;
+    int             buffer_height;
+    unsigned int    unk2[2];
+    ximr_layer      layers[8];
+    unsigned int    unk3[24];
+    unsigned char   denomx;
+    unsigned char   numerx;
+    unsigned char   denomy;
+    unsigned char   numery;
+    unsigned int    unk7;
+    short           width;
+    short           height;
+    unsigned int    unk4[27];
+} ximr_context;
+
+int display_needs_refresh = 0;
+
+#define FW_YUV_LAYER_BUF 0x41141000
+#define FW_YUV_LAYER_SIZE (960*270*2)
+#define FW_YUV_LAYER_FULLSIZE (960*270*2+960*270)
+#define CHDK_LAYER_BUF (((FW_YUV_LAYER_BUF+FW_YUV_LAYER_FULLSIZE)+0xff)&0xffffff00)
+
+unsigned char* chdk_rgba = 0;
+int chdk_rgba_init = 0;
+int bm_w;
+int bm_h;
+
+void vid_bitmap_erase()
+{
+    extern void _memset32(unsigned char *s, int n, unsigned int pattern);
+    _memset32(chdk_rgba, bm_w * bm_h * 4, 0);
+}
+
+int last_displaytype;
+
+/*
+ * Called when Canon is updating UI, via dry_memcpy patch.
+ * Sets flag for CHDK to update its UI.
+ * Also needed because bitmap buffer resolution changes when using HDMI
+ * LCD = 720 x 480
+ * HDMI = 960 x 540
+ */
+void update_ui(ximr_context* ximr)
+{
+    // Init RGBA buffer
+    if (chdk_rgba_init == 0)
+    {
+        chdk_rgba_init = 1;
+        chdk_rgba = (unsigned char*)CHDK_LAYER_BUF;
+        last_displaytype = -1;
+    }
+
+    // Make sure we are updating the correct layer - skip redundant updates for HDMI out
+    if (ximr->output_buf != (unsigned int)FW_YUV_LAYER_BUF)
+    {
+        // Update screen dimensions
+        if (last_displaytype != displaytype)
+        {
+            last_displaytype = displaytype;
+
+            if (ximr->buffer_width == 0x3c0) {
+                // no space for bigger horizontal res, unless...
+                bm_w = 720;
+                bm_h = 240;
+            } else {
+                bm_w = 720;
+                bm_h = 240;
+            }
+
+            camera_screen.width = bm_w;
+            camera_screen.height = bm_h;
+            camera_screen.buffer_width = bm_w;
+            camera_screen.buffer_height = bm_h;
+
+            // Reset OSD offset and width
+            camera_screen.disp_right = camera_screen.width - 1;
+            camera_screen.disp_width = camera_screen.width;
+
+            // Update other values
+            camera_screen.physical_width = camera_screen.width;
+            camera_screen.size = camera_screen.width * camera_screen.height;
+            camera_screen.buffer_size = camera_screen.buffer_width * camera_screen.buffer_height;
+
+            // Values for chdkptp live view
+            camera_screen.yuvbm_width = ximr->width;
+            camera_screen.yuvbm_height = ximr->height;
+            camera_screen.yuvbm_buffer_width = ximr->buffer_width;
+
+            // Clear buffer if size changed
+            vid_bitmap_erase();
+
+            // Tell CHDK UI that display needs update
+            display_needs_refresh = 1;
+        }
+
+        if (ximr->layers[0].bitmap == (unsigned int)FW_YUV_LAYER_BUF) {
+            ximr->layers[0].opacity = (unsigned int)(FW_YUV_LAYER_BUF+FW_YUV_LAYER_SIZE);
+            ximr->layers[0].src_h = 270;
+            ximr->layers[0].height = 270;
+            ximr->layers[0].scale = 4;      // x2 scaling vertically for the canon yuv layer
+        }
+
+        if (chdk_rgba != 0)
+        {
+            // Copy canon layer
+            memcpy(&ximr->layers[3], &ximr->layers[1], sizeof(ximr_layer));
+
+            // Remove offset
+            ximr->layers[3].scale = 4;      // x2 scaling vertically
+            ximr->layers[3].src_w = bm_w;
+            ximr->layers[3].src_h = bm_h;
+            ximr->layers[3].dst_x = 0;
+            ximr->layers[3].dst_y = 0;
+
+            // Set our buffer
+            ximr->layers[3].bitmap = (unsigned int)chdk_rgba;
+            ximr->layers[3].width = bm_w;
+            ximr->layers[3].height = bm_h;
+        }
+    }
+    else
+    {
+        ximr->output_opacitybuf = (unsigned int)(FW_YUV_LAYER_BUF+FW_YUV_LAYER_SIZE);
+        ximr->height = ximr->buffer_height = 270;
+        ximr->denomy = 0x6c;
+    }
+}

Quote from: Ant on 03 / May / 2021, 12:54:15

This will decrease the quality of Canon graphics

Samples attached.

untouched.jpg (263.8 kB, 1920x1080 - viewed 28 times.)

layer0_960x270.jpg (273.33 kB, 1920x1080 - viewed 31 times.)

Logged