I suspect this will cause other problems, although I'm not certain which parts of the code use bitmap height vs assuming it's the same as the CHDK viewport height. PTP live view would be affected, at least. This does explain why Adongy had so much trouble with the bitmap sizes.edit: wrong, see following discussion.

With DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY, the it shouldn't matter if the buffers aren't one buffer size apart. It seems like making zebra use only the active buffer on these cams shouldn't be a huge problem, and should perform better too.

We could also make get_bitmap_buffer(0|1), which by default would just do vid_get_bitmap_fb or vid_get_bitmap_fb + <width * height>, but could be overridden for these cams.

#undef CAM_BITMAP_HEIGHT #define CAM_BITMAP_HEIGHT 360I suspect this will cause other problems, although I'm not certain which parts of the code use bitmap height vs assuming it's the same as the CHDK viewport height.

There's also CAM_SCREEN_HEIGHT which is the height of the visible screen area. That is still 240, same as the viewport's height (AFAIK the overlay and the viewports can't have different sizes, not even on DIGIC 6). Does the zebra code not respect that?Side note: all those the overlay/viewport related definitions and helper functions (vid_get_viewport_height() and so on) make my head spin. They are one of the most confusing parts of a port.

There's also CAM_SCREEN_HEIGHT which is the height of the visible screen area. That is still 240, same as the viewport's height (AFAIK the overlay and the viewports can't have different sizes, not even on DIGIC 6). Does the zebra code not respect that?Side note: all those the overlay/viewport related definitions and helper functions (vid_get_viewport_height() and so on) make my head spin. They are one of the most confusing parts of a port.

Agreed. In fact, I was probably mixing up CAM_BITMAP_HEIGHT and CAM_SCREEN_HEIGHT in my earlier comment

I'm open to suggestions of how to make it clearer. Probably a topic for 1.5 and a different thread.

Does chdkptp live work correctly when CAM_BITMAP_HEIGHT = 360 on ixus150?

all those the overlay/viewport related definitions and helper functions (vid_get_viewport_height() and so on) make my head spin. They are one of the most confusing parts of a port.

CHDK IQ torture test

The idea was to move camera specific stuff into the port and out of the core code.I agree its complex; but there are a lot of variations of viewport and bitmap size, visible/hidden areas, offset etc. Some of these also change depending on the camera mode so are not fixed values.

If you can think of a way to simplify it that would be great; but making sure it works with all the combinations is tricky.

The idea was to move camera specific stuff into the port and out of the core code.

There's no problem with that, the CHDK core looks much better than ML's "core" which is riddled with camera-specific ifdefs.

Quote

If you can think of a way to simplify it that would be great; but making sure it works with all the combinations is tricky.

One of my concerns is that I see some possible future additions (pixel format for example) which would further complicate the mess of helper functions. Wouldn't it be possible to make one or more structs for keeping most overlay/viewport related information? Sort of like the existing camera_screen struct.For example, I found myself using camera_screen values while implementing port-specific functions needed for the experimental sx280 ptp live view support.

Quote

Documentation could be better though

Agree.

@reyalpit's probably time to split this discussion to the "1.5 plans" thread

@reyalpit's probably time to split this discussion to the "1.5 plans" thread

I think it's big enough for it's own thread

I agree with Phil quite a bit of the problem because that capturing the behavior of all the different cameras is actually complicated. For example, a lot of the viewport functions need to be functions, because they change at runtime on some cameras.

That said, it's really hard to tell at a glance what values a camera is using, or how those values ended up being used. We currently use values from:

I have always found the camera_info structures hard to follow, because it's very hard to tell which field a particular define goes in. I understand why it is that way (assigning in code would add significant size), but every time I look at those initializations I think there must be a better way.

Using both the camera_info values and the camera.h defines also makes it harder to keep track of, since you have to grep for both, and (because of the initialization thing) you don't see which defines go in which field.

Of course, any significant re-work is going to be difficult since it will require blind changes on a bunch of cams.