Display (bitmap overlay)

reyalp

14004

Re: Display (bitmap overlay)

« Reply #10 on: 05 / September / 2016, 02:33:35 »

Advertisements

Thanks for the zebra info.

Quote from: a1ex on 05 / September / 2016, 02:16:03

Do you have "hardware" focus peaking on any compacts before digic 6?

AFAIK no. I could be wrong, but I don't see any mention in the G15 or G1x manuals.

Logged

Don't forget what the H stands for.

Ant

509

Re: Display (bitmap overlay)

« Reply #11 on: 05 / September / 2016, 10:58:42 »

There is variable on EOS M3 that can turn on/off focus peaking (0x0000F9D8 for fw.v1.0.1)

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #12 on: 10 / September / 2016, 16:20:34 »

Quote from: reyalp on 27 / August / 2016, 18:13:02

The current drawing code uses active_bitmap_buffer as an index into opacity_buffer (without the &1 vid_get_active_bitmap_buffer uses ).

This is - partly - my fault (the original draw_pixel_std() also does that). It should probably be fixed as it can cause unpleasant surprises, especially for in-progress ports.
Doing the &1 operation may introduce some overhead in the pixel drawing routine - we could perhaps introduce a variable for (active_bitmap_buffer&1) and only update it in the spytask loop?

Logged

reyalp

14004

Re: Display (bitmap overlay)

« Reply #13 on: 10 / September / 2016, 17:05:47 »

Quote from: srsa_4c on 10 / September / 2016, 16:20:34

This is - partly - my fault (the original draw_pixel_std() also does that). It should probably be fixed as it can cause unpleasant surprises, especially for in-progress ports.

FWIW, on G7X at least it seams active_bitmap_buffer is only 0 or 1. But yes, results could be catastrophic if it ever had other values.

Quote

Doing the &1 operation may introduce some overhead in the pixel drawing routine -

Hmm, 1 register->register instruction only, but for every single pixel... still, it's should be much faster than the cams that write on both buffers. So I'm OK just having the &1 in gui_draw.c.

For d6 draw_pixel_std I'd probably calculate the current buffer once at the start.

Quote

we could perhaps introduce a variable for (active_bitmap_buffer&1) and only update it in the spytask loop?

Some drawing is also done in kbd_task. We could update in both, or just be OK with it being out of date some times.
If we do this, I'd suggest storing actual buffer addresses (bitmap for all, also opacity for d6), not just the index. Then they could just do something like
gui_draw_bitmap_buffer=vid_get_bitmap_active_buffer();
gui_draw_opacity_buffer=vid_get_opacity_active_buffer();
and the low level firmware variables would never have to be exposed.

I lean a little to the second option, but I don't have strong preference.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #14 on: 10 / September / 2016, 21:31:29 »

Quote from: reyalp on 10 / September / 2016, 17:05:47

FWIW, on G7X at least it seams active_bitmap_buffer is only 0 or 1. But yes, results could be catastrophic if it ever had other values.

active_bitmap_buffer is declared as int (which is a good choice for speed reasons). If someone doing a port chooses a fw var that is not an int ... - something like this may have caused the never ending failures of the sx700 port.

Quote

Hmm, 1 register->register instruction only, but for every single pixel... still, it's should be much faster than the cams that write on both buffers. So I'm OK just having the &1 in gui_draw.c.

For d6 draw_pixel_std I'd probably calculate the current buffer once at the start.
Quote
we could perhaps introduce a variable for (active_bitmap_buffer&1) and only update it in the spytask loop?
Some drawing is also done in kbd_task. We could update in both, or just be OK with it being out of date some times.
If we do this, I'd suggest storing actual buffer addresses (bitmap for all, also opacity for d6), not just the index. Then they could just do something like
gui_draw_bitmap_buffer=vid_get_bitmap_active_buffer();
gui_draw_opacity_buffer=vid_get_opacity_active_buffer();
and the low level firmware variables would never have to be exposed.

I guess your suggestion could further reduce the instruction count of draw_pixel_std() - I'd check the disassembly of the possible code variants and the benchmark too.
... and hope that it doesn't break the sx230. One of my theories is that some DIGIC 4 revisions have problems with accessing the same memory area via uncached CPU accesses and DMA (EDMAC) at the same time. I think one of the ML ports (500d?) suffers from something similar. edit: yes, src/zebra.c waveform_draw_image()

« Last Edit: 10 / September / 2016, 22:04:05 by srsa_4c »

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #15 on: 10 / October / 2016, 14:20:47 »

Quote from: reyalp on 10 / September / 2016, 17:05:47

Quote
Doing the &1 operation may introduce some overhead in the pixel drawing routine -
Hmm, 1 register->register instruction only, but for every single pixel... still, it's should be much faster than the cams that write on both buffers. So I'm OK just having the &1 in gui_draw.c.

I have experimented with this a bit, and ended up with the following:

Code: [Select]

Index: core/gui_draw.c
===================================================================
--- core/gui_draw.c	(revision 4702)
+++ core/gui_draw.c	(working copy)
@@ -40,7 +40,7 @@
 
     register int cli = cl ^ 0xffffffff;
     extern volatile char *opacity_buffer[];
-    //extern int active_bitmap_buffer;
+    int active_buffer_index =  active_bitmap_buffer & 1;
     static unsigned int prev_offs = 0xffffffff;
     register unsigned int offs2 = (offset>>1)<<2;
     if (cli != 0xffffffff)
@@ -47,39 +47,39 @@
     {
         if (prev_offs != offs2)
         {
-            bitmap_buffer[active_bitmap_buffer][offs2+2] = 0x80-((((int)cli)<<5)&0xe0);    // U?
-            bitmap_buffer[active_bitmap_buffer][offs2+0] = 0x80-((((int)cli)<<2)&0xe0);    // V?
+            bitmap_buffer[active_buffer_index][offs2+2] = 0x80-((((int)cli)<<5)&0xe0);    // U?
+            bitmap_buffer[active_buffer_index][offs2+0] = 0x80-((((int)cli)<<2)&0xe0);    // V?
             prev_offs = offs2;
         }
         if (offset&1) // x is odd
         {
-            bitmap_buffer[active_bitmap_buffer][offs2+3] = (cli&0xc0);    // Y
+            bitmap_buffer[active_buffer_index][offs2+3] = (cli&0xc0);    // Y
         }
         else // x is even
         {
-            bitmap_buffer[active_bitmap_buffer][offs2+1] = (cli&0xc0);    // Y
+            bitmap_buffer[active_buffer_index][offs2+1] = (cli&0xc0);    // Y
         }
         // simple transparency
-        opacity_buffer[active_bitmap_buffer][offset] = (cli&16)?0x60:0xff;
+        opacity_buffer[active_buffer_index][offset] = (cli&16)?0x60:0xff;
     }
     else // color==0, black, fully transparent
     {
         if (prev_offs != offs2)
         {
-            bitmap_buffer[active_bitmap_buffer][offs2+2] = 0x80;    // U?
-            bitmap_buffer[active_bitmap_buffer][offs2+0] = 0x80;    // V?
+            bitmap_buffer[active_buffer_index][offs2+2] = 0x80;    // U?
+            bitmap_buffer[active_buffer_index][offs2+0] = 0x80;    // V?
             prev_offs = offs2;
         }
         if (offset&1) // x is odd
         {
-            bitmap_buffer[active_bitmap_buffer][offs2+3] = 0;    // Y
+            bitmap_buffer[active_buffer_index][offs2+3] = 0;    // Y
         }
         else // x is even
         {
-            bitmap_buffer[active_bitmap_buffer][offs2+1] = 0;    // Y
+            bitmap_buffer[active_buffer_index][offs2+1] = 0;    // Y
         }
         // fully transparent
-        opacity_buffer[active_bitmap_buffer][offset] = 0;
+        opacity_buffer[active_buffer_index][offset] = 0;
     }
 #endif
 }

Introducing a local variable for the buffer index seems to speed up drawing a little, even with the added AND operation. Approx. +2.7 %, according to benchmark runs.

Logged

reyalp

14004

Re: Display (bitmap overlay)

« Reply #16 on: 11 / October / 2016, 01:01:34 »

Quote from: srsa_4c on 10 / October / 2016, 14:20:47

I have experimented with this a bit, and ended up with the following:
...
Introducing a local variable for the buffer index seems to speed up drawing a little, even with the added AND operation. Approx. +2.7 %, according to benchmark runs.

Thanks. Seems fine to me.

Faster is nice, but I wouldn't be much worried about performance unless it was a lot slower.

FWIW, it didn't affect the G7X MD crash.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #17 on: 11 / October / 2016, 20:21:44 »

Quote from: reyalp on 11 / October / 2016, 01:01:34

Thanks. Seems fine to me.

Committed. Good news for people trying to port a D6 camera.

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #18 on: 22 / January / 2017, 08:47:10 »

Found a full-screen Canon "dialog" that's just black and displays no text or graphical stuff. It's similar to DisplayBusyOnScreen - that means only one instance of it can exist, further attempts to display it again are ignored.
Seems like it doesn't exist on older DryOS (and VxWorks) cameras.
It's in the same library as DisplayBusyOnScreen (assert indicates the same source file). Can be found almost right after DisplayBusyOnScreen, UndisplayBusyOnScreen.
Examples (display_blank_screen, undisplay_blank_screen):
a3200 100d: 0xff8a1974 (seems unreferenced), 0xff8a1a14
sx280 102b: 0xfc14a2af, 0xfc14a327
m10 110d: 0xfc3274a1, 0xfc327541

Stuff I tried (sx280):
- display_blank_screen
- fill opacity buffers with 0 (just once)
- overlay disappears, viewport buffers (play or rec mode) become visible (and stay so)
...
- undisplay_blank_screen
- Canon overlay comes back

Above doesn't work from scripts (because CHDK issues several screen redraws while running scripts).

From memory, certain Canon graphical elements (e.g. low battery symbol) are positioned on top of any other screen elements, so those can disrupt the experience.

What could we do with the extra full screen dialog?

- fire it up in ALT mode and enjoy flickerless display
When a full screen dialog is visible, it's possible that changes to the source bitmap overlay (likely RGBA on DIGIC 6) are automatically copied onto the YUV and opacity buffers (this is just theory, may not actually work)*.
- display it when other full screen CHDK activity is going on (zebra, edge overlay, etc)

Update.

Turns out, DisplayBusyOnScreen and display_blank_screen use the same dialog resource and event callback. The resource contains (reference to) a hand icon and the "Busy" text, display_blank_screen hides both before displaying the dialog. No luck finding a background color property yet.

edit:
* Indeed, that's not working (tried on a DIGIC 4 cam).

edit2:
Pretty much everything written above can be disregarded. The firmware always redraws the whole overlay when it moves the focus rectangle around, even when the black dialog is on top and covers everything.

« Last Edit: 13 / March / 2017, 22:21:20 by srsa_4c »

Logged

srsa_4c

4451

Re: Display (bitmap overlay)

« Reply #19 on: 03 / February / 2017, 11:53:37 »

I'm trying a different approach to enlarge the font size on DIGIC 6 ports.
~~Cams with 3:2 or wider display will simply (not so simply, actually) use the current built-in font, at 200% magnification (16x32).~~
For the few models that have unfortunate 640x480 overlay, I'm planning to magnify the 8x16 font to 14x32. The horizontal part seems to be working (~~see image~~), hopefully it won't screw up non-Latin glyphs.

edit:
First implementation is working, draws ~5500 char/s with the default pixel drawing routine (to be improved).
Turns out, all D6 ports will have to use the same font size due to the way CHDK source is organized and built.
First try to implement a lookup-table based draw_pixel_std() routine was an utter failure (turned out to be slower than the current one that computes the colors).

font_14x32_demo.png (8.15 kB, 640x480 - viewed 84 times.)

« Last Edit: 04 / February / 2017, 13:55:47 by srsa_4c »

Logged