1.5 development planning thread - page 6 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9   Go Down

1.5 development planning thread

  • 89 Replies
  • 31233 Views
*

Offline srsa_4c

  • ******
  • 4416
Re: 1.5 development planning thread
« Reply #50 on: 06 / April / 2016, 17:37:14 »
Advertisements
Not sure where to post this (the bitmap overlay thread would have been the other choice).

Attached patch adds additional compression to the built-in font. It saves ~850 bytes when using the current font. The patch is not "production ready" yet, because it adds dead code (and an unnecessary runtime decision) to draw_char() in core/gui_draw.c .
Benchmark results are inconclusive, but it appears that the patched build on my a3200 actually draws text slightly faster than a vanilla build.

Background: while working on font related stuff, I've noticed that the built-in font uses less than half of the possible bit combinations in its font data.
I have added a lookup-table that contains the bytes that are actually used by the font bitmaps, made font_data[] use 7 bit lookup table indexes and used the remaining 1 bit as a "repetition flag". That allows sparing some bytes when encoding glyphs that have repeating rows.

I also have a use for those spared bytes: we could perhaps add the missing Greek letters...

Thoughts, improvements are welcome.
Logged
*

Offline philmoz

  • *****
  • 3326
    • Photos
Re: 1.5 development planning thread
« Reply #51 on: 07 / April / 2016, 21:10:07 »
Quote from: srsa_4c on 06 / April / 2016, 17:37:14
Not sure where to post this (the bitmap overlay thread would have been the other choice).

Attached patch adds additional compression to the built-in font. It saves ~850 bytes when using the current font. The patch is not "production ready" yet, because it adds dead code (and an unnecessary runtime decision) to draw_char() in core/gui_draw.c .
Benchmark results are inconclusive, but it appears that the patched build on my a3200 actually draws text slightly faster than a vanilla build.

Background: while working on font related stuff, I've noticed that the built-in font uses less than half of the possible bit combinations in its font data.
I have added a lookup-table that contains the bytes that are actually used by the font bitmaps, made font_data[] use 7 bit lookup table indexes and used the remaining 1 bit as a "repetition flag". That allows sparing some bytes when encoding glyphs that have repeating rows.

I also have a use for those spared bytes: we could perhaps add the missing Greek letters...

Thoughts, improvements are welcome.


My only reservation is that it puts a hard limit of 128 possible values that can exist for the font bitmaps - if extra font characters are needed that would exceed this limit, then it might be an issue. Probably very low risk though.


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

Offline srsa_4c

  • ******
  • 4416
Re: 1.5 development planning thread
« Reply #52 on: 08 / April / 2016, 17:37:10 »
Quote from: philmoz on 07 / April / 2016, 21:10:07
My only reservation is that it puts a hard limit of 128 possible values that can exist for the font bitmaps - if extra font characters are needed that would exceed this limit, then it might be an issue. Probably very low risk though.
I thought about that and provided a fallback in code.
For statistics: made three different 8x16 fonts so far, the worst case was a little over 110 distinct values in font data. The current font (as is) has 95.
Working on a more proper patch, forgot to modify draw_char_scaled().
Logged
*

Offline srsa_4c

  • ******
  • 4416
Re: 1.5 development planning thread
« Reply #53 on: 08 / April / 2016, 19:34:45 »
New patch.

font_8x16_pack now emits a #define when it managed to apply the rle compression.
core/gui_draw.c includes lib/font/font_8x16_uni_packed.h (but only to get the #define).
draw_char() and draw_char_scaled() have #ifdef'd parts, depending on the #define.
Since core/gui_draw.c now depends on lib/font/font_8x16_uni_packed.h, I made a change in platform/makefile_sub.inc accordingly.

On the a3200:
core code size increase: +108 bytes
font data: 3456 bytes + lookup table 95 bytes (font size without the rle compression is 4553 bytes)
Logged
*

Offline srsa_4c

  • ******
  • 4416
Re: 1.5 development planning thread
« Reply #54 on: 14 / April / 2016, 18:31:21 »
I realize this isn't likely to get discussed in detail (we're only a handful of people, no time, no-one here actually uses codepages other than cp1252), but here's the next update.

The core code part has not changed. I have added the missing Greek characters and while doing so, also updated the font to the current version (4.40).
I have added code to tools/font_8x16_pack that excludes repeated glyphs.
With this, the compressed font says
// font_data length: 3472 bytes
// lookup table length: 97 bytes
Logged
*

Offline philmoz

  • *****
  • 3326
    • Photos
Re: 1.5 development planning thread
« Reply #55 on: 15 / April / 2016, 00:11:08 »
Quote from: srsa_4c on 14 / April / 2016, 18:31:21
I realize this isn't likely to get discussed in detail (we're only a handful of people, no time, no-one here actually uses codepages other than cp1252), but here's the next update.

The core code part has not changed. I have added the missing Greek characters and while doing so, also updated the font to the current version (4.40).
I have added code to tools/font_8x16_pack that excludes repeated glyphs.
With this, the compressed font says
// font_data length: 3472 bytes
// lookup table length: 97 bytes


Looks good to me. Fitting in the extra characters while reducing the overall size is cool :)


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

Offline srsa_4c

  • ******
  • 4416
Re: 1.5 development planning thread
« Reply #56 on: 15 / April / 2016, 17:40:54 »
Quote from: philmoz on 15 / April / 2016, 00:11:08
Looks good to me. Fitting in the extra characters while reducing the overall size is cool :)
Thanks.
Attached the 'final' version, the only change is that I brought back the old dot (the dot we're using in checkboxes) because it has become smaller in version 4.40.
Also attached is an animation showing the old and new font. The new version can be easily recognized because the 1253 codepage screen is more complete. Order of codepages is:
1250 - 1251 - 1252
1253 - 1254 - 1257

I plan to check this in if there are no complaints. In, say, a week.

edit:
Committed.
Core size (between autobuild r4600 and r4601) decreased by approx. 860 bytes.
« Last Edit: 22 / April / 2016, 19:54:06 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4416
Re: 1.5 development planning thread
« Reply #57 on: 17 / June / 2016, 20:21:34 »
Attached is a patch that allows pausing/resuming continuous auto focus during video recording. This feature is for cameras that continuously adjust focus and don't have a native method for locking it.
I have re-used parts of the CAM_AF_SCAN_DURING_VIDEO_RECORD code, including the menu entry.
Two methods are implemented, one is based on the DoAFLock/UnlockAF firmware functions, the other uses the MovieAF.Suspend and MovieAF.Resume event procedures (only when these are available). The difference between the two methods is that DoAFLock always does an AF scan prior to locking the focus, MovieAF.Suspend just locks focus without an AF scan. If both methods are available, a menu entry lets the user choose one.

To avoid inadvertently leaving the focus locked, I placed a check in kbd_process() (core/kbd_process.c). I'm not sure if it's at the best location.

Cameras included in the patch are: ixus150, sx280, sx520/530. The MovieAF event procedures can be found in the funcs_by_name.csv files.

Previous version was posted in the sx530 thread.
Logged
*

Offline koshy

  • *****
  • 1063
Re: 1.5 development planning thread
« Reply #58 on: 25 / July / 2018, 19:55:20 »
This thread has been dormant for two years, what happened to 1.5?
It got stuck obviously but what is the status of it? ToDos, Goals?
I figured I'd nudge the thread to see what happens...
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline waterwingz

  • ******
  • 12086
    • Waterwingz
Re: 1.5 development planning thread
« Reply #59 on: 25 / July / 2018, 20:03:21 »
Well, the number of active devs has dwindled to about two. Or maybe three if you count my UI3.0 stuff. 

Personal stuff has consumed my time but if a few people indicated the UI3 stuff was sufficiently cool I could get fired up to complete this / start the first release in the coming months.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 2 3 4 5 [6] 7 8 9   Go Up
« previous next »
 

Related Topics