In general, knowing what frame range you render is reasonable, however am not sure of this patch.

Pros:

• Assigning rd = scene->r after executing the Python script so as to take the values modified by Python.
• Assigning scene->r.cfra before rendering a frame seems OK too.
  
  However: render_init called from RE_BlenderAnim won't have the current frame set, where it would for RE_BlenderFrame
  
  (trivial to set to first frame - just noting it as an inconsistency in this patch).

Cons:

• This adds some hidden logic, making render_init a special case.
  
  You can't - for example, access the real values on other handlers - render_pre/post/complete/cancel.
  
  This means developers need to know that temp values are used in a specific handler. (that can be documented of course, but is a bit awkward).

Possible alternative:

The current design doesn't fit well with Python accessing and manipulating these values.

However instead of this patch, it may be better to expose scene.render_runtime for eg. which will be None (NULL) when not actively rendering. Then scripts can access the stack render-data, and we don't have to fake swapping values.

An issue with this - is if a scene is being rendered more than once, (since it could have multiple render_runtime's), and it would get messy if we end up having our own internal code accessing this.

Interested what other devs thing - @Brecht Van Lommel (brecht)/@Bastien Montagne (mont29)/@Sergey Sharybin (sergey) ?

I can see my patch is the wrong way to go.

Regarding the current frame, it should probably be classed as undefined while in a render_init handler, but classed as defined while in later event handlers e,g. 'frame_change_post', 'render_pre'

I'm not sure it's relevant to the discussion you may have but the AddOn I was creating was to add an overscan border to a render - increase the image size of the render whilst keeping the 'non overscaned' part of the image, pixel perfect to an image rendered without overscan. This is achieved by changing the render resolution and the camera sensor size. The way I wanted to do this was to append the UI ('use ovescan' check-box + 'width' and 'height' properties) to the RENDER_PT_dimensions panel and change the render image size and sensor size in a render_init handler (and undo changes in render_cancel/complete). The way I ended up doing it was to create a separate UI panel with 'Render with Overscan' and 'Animation with Overscan' buttons and get the button operators to set up values before initiating the rendering.

For me, appending the UI to the RENDER_PT_dimensions panel just feels like the right way to do it.

Compile in GCC, use correct types for SWAP

Sorry, silly mistake - I must've been coding while sleeping.