- Messages
- 268
- Country
This outlines some thought I had concerning the interfaces for generating background images for the main workarea (the map).
With background image I basically refers to anything that can't be edited in any way but helps the user to position objects etc. Think for example sattallite photos (when not doing photoreal obviously as they would then be part of the scenery), GIS data, or data read from the FS scenery files directly.
I imagine splitting the task in two parts, where one part is responsible for keeping both the image rendering and the view simple.
Notice this is "notepad" code, it won't run - it is just here to get the basic overview.
First the interface of the service responsible for
public interface IBackgroundImageService : IDisposable
{
void SetView(AreaG area, Size size, BackgroundImageGeneratedDelegate callback);
}
public interface IBackgroundImageGeneratedResult
{
Image BackgroundImage { get; }
AreaG area { get; }
}
AreaG is a struct containing a min/max latitude and longitude. I already have some code we could modify (read: clean up) and use for this. Notice I am missing one method on the first interface used to set the various background image sources used - it can be added later and is not important for the architecture.
Seen from the view, all that is needed is setting the area to show and the size of the view in pixels. It will then receive a number of callbacks with the image to use as background for the specified area. If the view is moved, the view can use the parts it still has visible (might be strectched a bit until the correct image is ready).
Notice a callback is used indstead of the more logical event to avoid sending the bitmap to more than one destination, which would make it unclear who should dispose it.
A background thread will then be used to render the image. Any prefetching, caching (if possible) etc will be done at this level so the view can be kept simple.
The properties of the varipous renderes (see below) will be monitored and if changed a new render operation will be started.
The actual rendering will be done by calling one or more sevices implementing the following interface and then combining the result:
public interface IBackgroundImageRenderService : IDisposable
{
IProperties CreateDefaultProperties();
Image RenderImage(AreaG area, Size size, IProperties Properties);
}
CreateDefaultProperties is not that interesting (and may not be needed) - it is just there to allow us to get default properties we can then let the user modify.
RenderImage befores the actual drawing into a bitmap using the specified properties. It does not have to be multithreaded as this will be delt with from the caller, but it must support being canceled with a ThreadInterrupt exception.
With background image I basically refers to anything that can't be edited in any way but helps the user to position objects etc. Think for example sattallite photos (when not doing photoreal obviously as they would then be part of the scenery), GIS data, or data read from the FS scenery files directly.
I imagine splitting the task in two parts, where one part is responsible for keeping both the image rendering and the view simple.
Notice this is "notepad" code, it won't run - it is just here to get the basic overview.
First the interface of the service responsible for
public interface IBackgroundImageService : IDisposable
{
void SetView(AreaG area, Size size, BackgroundImageGeneratedDelegate callback);
}
public interface IBackgroundImageGeneratedResult
{
Image BackgroundImage { get; }
AreaG area { get; }
}
AreaG is a struct containing a min/max latitude and longitude. I already have some code we could modify (read: clean up) and use for this. Notice I am missing one method on the first interface used to set the various background image sources used - it can be added later and is not important for the architecture.
Seen from the view, all that is needed is setting the area to show and the size of the view in pixels. It will then receive a number of callbacks with the image to use as background for the specified area. If the view is moved, the view can use the parts it still has visible (might be strectched a bit until the correct image is ready).
Notice a callback is used indstead of the more logical event to avoid sending the bitmap to more than one destination, which would make it unclear who should dispose it.
A background thread will then be used to render the image. Any prefetching, caching (if possible) etc will be done at this level so the view can be kept simple.
The properties of the varipous renderes (see below) will be monitored and if changed a new render operation will be started.
The actual rendering will be done by calling one or more sevices implementing the following interface and then combining the result:
public interface IBackgroundImageRenderService : IDisposable
{
IProperties CreateDefaultProperties();
Image RenderImage(AreaG area, Size size, IProperties Properties);
}
CreateDefaultProperties is not that interesting (and may not be needed) - it is just there to allow us to get default properties we can then let the user modify.
RenderImage befores the actual drawing into a bitmap using the specified properties. It does not have to be multithreaded as this will be delt with from the caller, but it must support being canceled with a ThreadInterrupt exception.
given that the area of ground that we generally use when designing scenery is quite small is projection going to matter. Must admit it had not occurred to me as something to worry about.