Display (bitmap overlay)

Ant

509

Re: Display (bitmap overlay)

« Reply #150 on: 28 / February / 2019, 14:33:32 »

Advertisements

Quote from: srsa_4c on 28 / February / 2019, 14:12:45

I started collecting bigger logs by using one of the RAM areas that appear to be unused for a longer time.

Why don't you use _exmem_alloc ?
It gives me at least 16MB.

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #151 on: 28 / February / 2019, 14:51:07 »

Quote from: Ant on 28 / February / 2019, 14:33:32

Why don't you use _exmem_alloc ?
It gives me at least 16MB.

That could work too, of course. But knowing those seldom used areas can be useful - logging stuff before the OS starts, for example.
I'm unable to fill more than 0x1a000000 bytes of uncached RAM (done in the very first lines of boot.c) using memset32 - a watchdog shuts down the cam if I attempt more.

Logged

Ant

509

Re: Display (bitmap overlay)

« Reply #152 on: 28 / February / 2019, 15:06:52 »

Quote

In playback mode when multiple thumbnails are shown at once, scrolling through them at max speed (by holding down 'up' or 'down') fires jedidraw messages where that byte is less than 100.

These thumbnails don't look transparent.
I assume that MZRM can't render transparent bitmaps.

« Last Edit: 28 / February / 2019, 15:11:14 by Ant »

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #153 on: 28 / February / 2019, 15:13:54 »

Quote from: Ant on 28 / February / 2019, 15:06:52

This thumbnails don't look transparent.

No, and it happens too fast to observe. It's also possible that the M3 version is different. Log a session in which you do the thumbnail scroll and look for any changes in those 0x64 bytes.

Logged

Ant

509

Re: Display (bitmap overlay)

« Reply #154 on: 28 / February / 2019, 15:34:17 »

Quote from: srsa_4c on 28 / February / 2019, 15:13:54

It's also possible that the M3 version is different.

What about SX280?

Quote

No, and it happens too fast to observe.

The thumbnails are drawn on a gray background. So I don't see it even on CHDK-PTP screenshots.

Quote

Log a session in which you do the thumbnail scroll and look for any changes in those 0x64 bytes.

Have you managed to render transparent bitmaps from your code?

« Last Edit: 28 / February / 2019, 15:37:35 by Ant »

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #155 on: 28 / February / 2019, 16:17:02 »

Quote from: Ant on 28 / February / 2019, 15:34:17

What about SX280?

Not yet. I'll probably port the "aborttrick" version to this cam. But it is 1st generation so I don't have high hopes.

Quote

Have you managed to render transparent bitmaps from your code?

Yes, but as I said, the byte I found is about mixing new overlay with the old. When used repeatedly, the transparent bitmap will turn opaque sooner or later.

m10_mixed.png (363.57 kB, 720x480 - viewed 42 times.)

Logged

Ant

509

Re: Display (bitmap overlay)

« Reply #156 on: 02 / March / 2019, 10:27:52 »

But new overlay still contain a black area that should be fully transparent to be used as CHDK layer.
Maybe it's better to replace one of rgba buffers in XimrExe message or add the third buffer(if it possible)?

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #157 on: 02 / March / 2019, 14:31:06 »

Quote from: Ant on 02 / March / 2019, 10:27:52

But new overlay still contain a black area that should be fully transparent to be used as CHDK layer.

The source bitmap has no transparency information, so whatever its background is, it will remain visible. I wonder if rgba bitmaps are supported by one of the methods (JD or not). Ximrexe does support rgba as source, but its destination is yuv+opacity, and I can't recall whether it can enlarge images.

Quote

Maybe it's better to replace one of rgba buffers in XimrExe message or add the third buffer(if it possible)?

We can't control which of the rgba buffers is used for which kind of content, plus we can't control the active yuv+opacity buffer. The latter can fluctuate quite often in some modes.
Plus, if ximrexe can't upscale images, we'd need a full size rgba buffer. With jedidraw, we could use a 720x240 yuv buffer and draw on it like on classic powershots (360x240).

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #158 on: 10 / March / 2019, 11:54:35 »

No real progress, just observations.
The sx280 constructs a large (taller than overlay's height) yuv bitmap in playback mode's thumbnail view, rather than drawing the thumbnails one-by-one. I found the larger jedidraw struct to be seemingly always 128 bytes long. Unfortunately, its yuv bitmap mode refers to a (probably previously prepared) external MARV struct that also refers to other structs...
I collected some statistics about the mzrm messages actually used in playback and rec mode (it's possible that some of the other messages are also used under different circumstances). The attachment (.ods file in 7z) lists all messages of sx280 and m10 together with the number of uses in a few minute session. The usage counts are in hex.

mzrm_msg_use.7z (15.01 kB - downloaded 16 times.)

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #159 on: 15 / July / 2019, 17:50:43 »

I accidentally discovered that there is a way to disable most of the Canon overlay drawings on newer cameras. From approx. DryOS r52 on, there is an event procedure named SetWindowSystemDrawSetting. It just sets a global variable which I named canon_drawing_enabled. It is 1 by default, setting it to 0 makes the Canon overlay drawing code skip its main drawing path. Not affected are: mostly animated icons and buffer switches. Still, it makes CHDK menu browsing in rec mode a bit more comfortable. Example implementation for two of my cameras follows.

Code: [Select]

Index: platform/ixus150_elph140/lib.c
===================================================================
--- platform/ixus150_elph140/lib.c	(revision 5233)
+++ platform/ixus150_elph140/lib.c	(working copy)
@@ -113,6 +113,18 @@
     _ScreenUnlock();
 }
 
+extern int canon_drawing_enabled;
+
+void vid_turn_off_updates()
+{
+    canon_drawing_enabled = 0;
+}
+
+void vid_turn_on_updates()
+{
+    canon_drawing_enabled = 1;
+}
+
 int vid_get_palette_type()   { return 5; }
 int vid_get_palette_size()   { return 256 * 4 ; }
 
Index: platform/ixus150_elph140/sub/100c/stubs_min.S
===================================================================
--- platform/ixus150_elph140/sub/100c/stubs_min.S	(revision 5233)
+++ platform/ixus150_elph140/sub/100c/stubs_min.S	(working copy)
@@ -29,3 +29,5 @@
 DEF(video_target_framesize2, 0xBDB0) // approx. 2*video_target_framesize (for intraframes?), found in sub_FFAB938C
 //DEF(video_framesize, 0x70f0) // most recent frame's compressed size, found at 0xFF993D74
 //DEF(video_frame_data, 0x70f4) // most recent frame's RAM address
+
+DEF(canon_drawing_enabled, 0x7b60) // 0x7b54 + 0xc, from SetWindowSystemDrawSetting_FW
Index: platform/sx280hs/lib.c
===================================================================
--- platform/sx280hs/lib.c	(revision 5233)
+++ platform/sx280hs/lib.c	(working copy)
@@ -8,6 +8,18 @@
     _transfer_src_overlay(1);
 }
 
+extern int canon_drawing_enabled;
+
+void vid_turn_off_updates()
+{
+    canon_drawing_enabled = 0;
+}
+
+void vid_turn_on_updates()
+{
+    canon_drawing_enabled = 1;
+}
+
 void shutdown() {
 //***TODO***
 /*
Index: platform/sx280hs/sub/102b/stubs_min.S
===================================================================
--- platform/sx280hs/sub/102b/stubs_min.S	(revision 5233)
+++ platform/sx280hs/sub/102b/stubs_min.S	(working copy)
@@ -51,3 +51,5 @@
 //FAKEDEF(enabled_refresh_physical_screen,    1)
 
 DEF(displaytype,                            0x8eb8) //0x8ea4 + 0x14, found  @ fc135f2a (GetDisplayType)
+
+DEF(canon_drawing_enabled, 0x12ad0) // 0x12ac4 + 0xc, from SetWindowSystemDrawSetting_FW
Index: platform/sx280hs/sub/102c/stubs_min.S
===================================================================
--- platform/sx280hs/sub/102c/stubs_min.S	(revision 5233)
+++ platform/sx280hs/sub/102c/stubs_min.S	(working copy)
@@ -51,3 +51,5 @@
 //FAKEDEF(enabled_refresh_physical_screen,    1)
 
 DEF(displaytype,                            0x8eb8) //0x8ea4 + 0x14, found  @ fc135f2a (GetDisplayType)
+
+DEF(canon_drawing_enabled, 0x12ad0) // 0x12ac4 + 0xc, from SetWindowSystemDrawSetting_FW

This global variable and its support code is completely missing from earlier cameras, so this method only helps those more recent models.

edit:
There is not a lot of talk about vid_turn_off_updates() and vid_turn_on_updates(). Turns out, using ScreenLock() and ScreenUnlock() in those functions seems to get rid of all Canon overlay updates, but the black screen side effect is still there when trying on sx280.

« Last Edit: 15 / July / 2019, 18:22:57 by srsa_4c »

Logged