1.4 development planning thread - page 3 - General Discussion and Assistance - CHDK Forum  

1.4 development planning thread

  • 195 Replies
  • 47678 Views
*

Offline reyalp

  • ******
  • 13357
Re: 1.4 development planning thread
« Reply #20 on: 02 / January / 2015, 18:35:11 »
Advertisements
* srsa' digic 6 support and ports
It's perhaps time for me to start asking questions about this one. I'm not sure what's the best place to do it, so I'm starting here.
First, that item was just a suggestion, if it's not ready that's fine with me. Reconciling them will only get harder over time though. I haven't looked at the the code seriously yet, and Santa failed to put a Digic 6 cam in the stocking :P

Quote
First, my main concerns now are:
- putting DIGIC 6 support code in trunk would make backports of bugfixes/enhancements even more difficult due to the number of changes
Do you mean backports from 1.4 to 1.3, or into your code?

Quote
- there's already a huge amount of new features in current trunk, waiting to be tested/stabilized
This is true. Are you concerned destabilizing the trunk more, or that the Digic 6 ports will be more unstable?

Quote
- once DIGIC 6 support is in, every change in UI (etc.) will need to take the new display resolutions (, framebuffer formats, CPU) into account
Currently, I'm not even trying to keep my DIGIC 6 "fork" up-to-date, because
- resolving conflicts would take a considerable amount of time
- I'm using lots of "hacks" which I think should be done differently, keeping these updated seems like wasted time to me

What do you guys think would be the best approach for integration?
Maybe the place to figuring out ways to deal with those hacks and platform specifics, before actually trying to merge them. So for example if the display code needs more abstractions we can try to put those into the trunk. If you can highlight the problem areas, some of us may be able to help with that.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #21 on: 02 / January / 2015, 19:07:36 »
Reconciling them will only get harder over time though.
Yes.
Quote
I haven't looked at the the code seriously yet, and Santa failed to put a Digic 6 cam in the stocking :P
I don't expect you (or someone else) to review all details at once, since all persistent members have their own projects.
At this point it seems unlikely that other people will turn up and take care of DIGIC 6 related development - the "unusually" hard nature of DIGIC 6 porting alone seems to scare potential developers off. That's why I started working on it - but my abilities are limited.
Quote
Do you mean backports from 1.4 to 1.3, or into your code?
1.3
Quote
This is true. Are you concerned destabilizing the trunk more, or that the Digic 6 ports will be more unstable?
I hope it won't "destabilize" trunk, it just means more details to watch out for. I'm not even mentioning that the UI will have to be more or less reworked to present a pleasant experience on high resolution displays...
Quote
Maybe the place to figuring out ways to deal with those hacks and platform specifics, before actually trying to merge them. So for example if the display code needs more abstractions we can try to put those into the trunk. If you can highlight the problem areas, some of us may be able to help with that.
I'll try to come up with some kind of a list. Shall I continue this here or in the generic DIGIC 6 thread?

*

Offline reyalp

  • ******
  • 13357
Re: 1.4 development planning thread
« Reply #22 on: 02 / January / 2015, 19:28:21 »
Quote
Do you mean backports from 1.4 to 1.3, or into your code?
1.3
I wouldn't worry too much about this. We don't tend to do a huge amount of backporting, and the trunk as already diverging quite bit.

Quote
I'll try to come up with some kind of a list. Shall I continue this here or in the generic DIGIC 6 thread?
I'd say in that thread, I imagine there will be more than a couple of posts worth of discussion.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #23 on: 02 / January / 2015, 22:08:17 »
Quote
I'll try to come up with some kind of a list. Shall I continue this here or in the generic DIGIC 6 thread?
I'd say in that thread, I imagine there will be more than a couple of posts worth of discussion.
Continued here: http://chdk.setepontos.com/index.php?topic=11316.msg119595#msg119595


*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: 1.4 development planning thread
« Reply #24 on: 03 / January / 2015, 03:27:14 »
Currently on my todo list (may not get around to all of these):
  • Cleanup / rework of the gui_draw.c code. We don't really need 13 different functions for drawing a rectangle, so I plan to simplify this code. There are also some improvements I think can be made to text/string drawing. Management of the screen real-estate for touch screen cams that use on-screen buttons is also in line for some rework.
  • Remove hard wired games menu, and build at run time from modules tagged with a 'GAME' module type. Add another menu for 'custom modules' built at runtime and tagged with a specific type (allows user created modules to be included without editing any menus). These should be safe to do now that the file IO issues are fixed.
  • Tv & Av data types for script parameters built from actual values from camera tables.

Phil.
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)

Re: 1.4 development planning thread
« Reply #25 on: 03 / January / 2015, 08:55:46 »
Tv & Av data types for script parameters built from actual values from camera tables.
Sv ?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 13357
Re: 1.4 development planning thread
« Reply #26 on: 03 / January / 2015, 15:16:07 »
I like all of these :)
Cleanup / rework of the gui_draw.c code. We don't really need 13 different functions for drawing a rectangle, so I plan to simplify this code. There are also some improvements I think can be made to text/string drawing. Management of the screen real-estate for touch screen cams that use on-screen buttons is also in line for some rework.
One thing I was thinking about was re-using the ellipse, line and font drawing for raw hooks. I'm not sure those could be made generic without noticeable performance impact, just an idle thought at this point. The draw pixel function is already variable, but it's a global, and the color specification will be different for raw (an RGB or RGBG, with the functions drawing in 4 pixel units).
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: 1.4 development planning thread
« Reply #27 on: 03 / January / 2015, 16:50:48 »
I like all of these :)
Cleanup / rework of the gui_draw.c code. We don't really need 13 different functions for drawing a rectangle, so I plan to simplify this code. There are also some improvements I think can be made to text/string drawing. Management of the screen real-estate for touch screen cams that use on-screen buttons is also in line for some rework.
One thing I was thinking about was re-using the ellipse, line and font drawing for raw hooks. I'm not sure those could be made generic without noticeable performance impact, just an idle thought at this point. The draw pixel function is already variable, but it's a global, and the color specification will be different for raw (an RGB or RGBG, with the functions drawing in 4 pixel units).

Probably easier to take a copy of the required code initially, may need tweaking to improve performance on RAW images. You could still use the CHDK color values for drawing with a lookup table to convert to RGBG.

I'm assuming at some point the raw hook C code will move to a module so the memory hit will only occur when you actually need it.

Phil.
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

  • ******
  • 4426
Re: 1.4 development planning thread
« Reply #28 on: 03 / January / 2015, 17:09:20 »
Just FYI, there's an old mod for custom timestamps, not sure how useful it is now. Final patch is on its 7th page.

*

Offline reyalp

  • ******
  • 13357
Re: 1.4 development planning thread
« Reply #29 on: 03 / January / 2015, 17:36:57 »
I'm assuming at some point the raw hook C code will move to a module so the memory hit will only occur when you actually need it.
The drawing / meter / histogram code is in the lua module right now, but yeah I plan for it to go in it's own module at some point.

There may also be cases for using it outside of script, like the timestamp mod srsa linked or extensions to the continuous mode bracketing function. I'll post more about the second idea in the hook thread shortly...
Don't forget what the H stands for.

 

Related Topics