supplierdeeply

Display (bitmap overlay)

  • 76 Replies
  • 10967 Views
*

Offline reyalp

  • ******
  • 10414
Re: Display (bitmap overlay)
« Reply #10 on: 05 / September / 2016, 02:33:35 »
Advertisements
Thanks for the zebra info.
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.
Don't forget what the H stands for.

*

Offline Ant

  • ****
  • 254
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)

*

Offline srsa_4c

  • ******
  • 3393
Re: Display (bitmap overlay)
« Reply #12 on: 10 / September / 2016, 16:20:34 »
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?

*

Offline reyalp

  • ******
  • 10414
Re: Display (bitmap overlay)
« Reply #13 on: 10 / September / 2016, 17:05:47 »
:-[
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.
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 3393
Re: Display (bitmap overlay)
« Reply #14 on: 10 / September / 2016, 21:31:29 »
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 »

*

Offline srsa_4c

  • ******
  • 3393
Re: Display (bitmap overlay)
« Reply #15 on: 10 / October / 2016, 14:20: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.

*

Offline reyalp

  • ******
  • 10414
Re: Display (bitmap overlay)
« Reply #16 on: 11 / October / 2016, 01:01:34 »
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.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3393
Re: Display (bitmap overlay)
« Reply #17 on: 11 / October / 2016, 20:21:44 »
Thanks. Seems fine to me.
Committed. Good news for people trying to port a D6 camera.


*

Offline srsa_4c

  • ******
  • 3393
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 »

*

Offline srsa_4c

  • ******
  • 3393
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).
« Last Edit: 04 / February / 2017, 13:55:47 by srsa_4c »

 

Related Topics